Tarif und Ausstattung – Caddy als Webserver: wie automatische Zertifikate die Verwaltung vereinfachen

Lesedauer: 9 Min
Aktualisiert: 17. September 2026 04:43
Transparenz: Bei der Erstellung dieses Beitrags kam generative KI zum Einsatz.

Caddy eignet sich besonders für einen kleinen VPS, wenn HTTPS ohne separate Zertifikatswerkzeuge eingerichtet und dauerhaft gepflegt werden soll. Der Webserver kann TLS-Zertifikate automatisch anfordern, installieren und erneuern, sofern Domain, DNS, Erreichbarkeit und persistenter Speicher richtig vorbereitet sind. Für die Tarifwahl sind deshalb weniger die Zertifikate selbst als RAM, CPU-Leistung, Speicher, Traffic sowie die dahinter ausgeführte Anwendung maßgeblich. Ein günstiger Tarif reicht für einfache Websites häufig aus; Datenbanken, Shops, mehrere Container und rechenintensive Anwendungen bestimmen den Ressourcenbedarf wesentlich stärker als Caddy.

Was Caddy bei der TLS-Verwaltung tatsächlich übernimmt

Caddy aktiviert für geeignete Domainnamen standardmäßig Automatic HTTPS. Dazu beschafft der Webserver ein passendes Zertifikat über das ACME-Verfahren, speichert Zertifikat und Schlüssel und kümmert sich vor dem Ablauf um die Verlängerung. Auch die Weiterleitung von unverschlüsseltem HTTP zu HTTPS gehört normalerweise zu diesem Ablauf.

Der Verwaltungsgewinn liegt vor allem darin, dass kein eigener Zertifikatsclient mit separaten Zeitplänen, Webroot-Pfaden und Reload-Skripten gepflegt werden muss. Nach einer erfolgreichen Erneuerung kann Caddy das neue Zertifikat selbst verwenden. Das senkt die Zahl der beweglichen Teile und vermeidet typische Abstimmungsfehler zwischen Webserver, Zertifikatswerkzeug und Systemdienst.

Automatic HTTPS ersetzt jedoch weder die Pflege des Servers noch eine Kontrolle der Erreichbarkeit. Betriebssystem, Caddy-Version, Anwendung und Datenbank benötigen weiterhin Sicherheitsupdates. Ebenso bleiben Monitoring, Backups und eine saubere Wiederherstellungsplanung erforderlich.

Vier Voraussetzungen entscheiden über die automatische Ausstellung

Die Automatisierung funktioniert nur, wenn Caddy die Domain eindeutig bedienen und die Validierung erfolgreich abschließen kann. Vor der Tarifbuchung und Inbetriebnahme sollten vier Punkte geklärt sein:

  1. Domain und DNS: Der verwendete Hostname muss auf die öffentliche Adresse des Servers zeigen. Nach einer Änderung kann es dauern, bis alte DNS-Antworten aus Zwischenspeichern verschwunden sind.
  2. Erreichbare Standardports: Für übliche Validierungswege und den späteren Webbetrieb müssen TCP-Port 80 und TCP-Port 443 aus dem Internet erreichbar sein. Provider-Firewalls, lokale Firewalls, vorgeschaltete Router oder andere Dienste dürfen diese Ports nicht unpassend blockieren oder belegen.
  3. Persistenter Datenspeicher: Caddys Datenverzeichnis muss Neustarts, Updates und eine Neuerstellung des Containers überstehen. Dort liegen unter anderem Zertifikate, Schlüssel und Verwaltungsdaten.
  4. Passende Caddy-Konfiguration: Der Domainname muss in der aktiven Konfiguration korrekt erscheinen. Bei einer Reverse-Proxy-Konfiguration muss außerdem das interne Ziel erreichbar sein, auch wenn die Zertifikatsausstellung davon technisch getrennt abläuft.

Eine öffentliche IPv4-Adresse ist nicht in jedem Aufbau zwingend, kann den Betrieb aber vereinfachen. Ein ausschließlich über IPv6 erreichbarer Server setzt voraus, dass DNS, Besucherzugänge und alle beteiligten Dienste zuverlässig mit IPv6 funktionieren. Wird ein vorgeschalteter Proxy oder ein Load Balancer verwendet, muss klar sein, an welcher Stelle TLS endet und welche Instanz die Zertifikate verwaltet.

Der passende Tarif richtet sich nach der Anwendung hinter Caddy

Caddy selbst kann statische Dateien ausliefern oder als Reverse Proxy Anfragen an Anwendungen und Container weitergeben. Im zweiten Fall nimmt Caddy die öffentliche HTTPS-Verbindung an und leitet die Anfrage intern beispielsweise an einen Webdienst weiter. Der Tarif muss daher für den gesamten Softwarestapel dimensioniert werden, nicht nur für den vorgeschalteten Webserver.

Statische Website oder kleine Weiterleitungsseite

Bei wenigen statischen Seiten sind CPU- und RAM-Anforderungen meist gering. Wichtiger sind eine verlässliche Netzwerkanbindung, ausreichender Traffic und genügend Speicher für Betriebssystem, Protokolle und Sicherungen. Selbst bei einem schmalen Tarif sollte etwas freier RAM vorhanden sein, damit Updates und kurzfristige Lastspitzen nicht sofort zu Speichermangel führen.

Anleitung
1Domain und DNS: Der verwendete Hostname muss auf die öffentliche Adresse des Servers zeigen. Nach einer Änderung kann es dauern, bis alte DNS-Antworten aus Zwischenspeich….
2Erreichbare Standardports: Für übliche Validierungswege und den späteren Webbetrieb müssen TCP-Port 80 und TCP-Port 443 aus dem Internet erreichbar sein. Provider-Firewal….
3Persistenter Datenspeicher: Caddys Datenverzeichnis muss Neustarts, Updates und eine Neuerstellung des Containers überstehen. Dort liegen unter anderem Zertifikate, Schlü….
4Passende Caddy-Konfiguration: Der Domainname muss in der aktiven Konfiguration korrekt erscheinen. Bei einer Reverse-Proxy-Konfiguration muss außerdem das interne Ziel er….

Kleine Webanwendung mit Datenbank

Sobald eine Anwendung, eine Laufzeitumgebung und eine Datenbank hinzukommen, verlagert sich der Bedarf. Datenbank-Cache, Hintergrundaufgaben und parallele Anfragen beanspruchen den Arbeitsspeicher. Eine NVMe- oder SSD-basierte Ablage kann für Datenbanken und viele kleine Dateizugriffe wichtiger sein als zusätzliche CPU-Kerne. Caddy bleibt in diesem Aufbau häufig nur ein kleiner Teil des Gesamtverbrauchs.

Mehrere Websites oder Container

Mehrere Dienste lassen sich mit Caddy unter unterschiedlichen Hostnamen bereitstellen. Der Ressourcenbedarf ergibt sich dabei aus der Summe der Anwendungen zuzüglich einer Reserve. Ein Tarif mit etwas mehr RAM ist oft sinnvoller als ein knapp bemessener Plan, bei dem schon ein paralleles Update mehrerer Container den Speicher ausschöpft.

Bei der CPU-Angabe ist zwischen vCPU und dedizierten Kernen zu unterscheiden. Eine vCPU ist eine vom Anbieter bereitgestellte virtuelle Recheneinheit, deren tatsächliche Leistung von Prozessor, Virtualisierung und möglicher Mitnutzung abhängt. Dedizierte Kerne bieten besser abgrenzbare Ressourcen, sind für eine einfache Caddy-Installation aber selten allein wegen der TLS-Verwaltung nötig.

Tarifmerkmale, die für Caddy mehr zählen als ein niedriger Grundpreis

Ein belastbarer Vergleich beginnt mit dem regulären Gesamtpreis und einer einheitlichen Laufzeit. Ein Aktionspreis für die ersten Monate lässt sich nicht direkt mit einem dauerhaft geltenden Monatspreis vergleichen. Ebenso müssen Umsatzsteuer, Einrichtungsgebühr und kostenpflichtige Optionen auf derselben Basis betrachtet werden.

  • RAM: Entscheidend ist der Gesamtbedarf von Caddy, Anwendung, Datenbank, Betriebssystem und weiteren Diensten. Garantierter Arbeitsspeicher ist für einen dauerhaft betriebenen Webserver besser planbar als unklar beschriebener dynamischer Speicher.
  • CPU: Prüfe Anzahl und Art der vCPUs sowie mögliche Hinweise zur dauerhaften Auslastung. Kurzzeitige Spitzen und dauerhaft hohe Rechenlast sind tariflich nicht immer gleich behandelt.
  • Speicher: Neben der Kapazität zählen Speichertechnik, nutzbarer Platz und die Möglichkeit von Snapshots oder Backups. Das Caddy-Datenverzeichnis beansprucht wenig Platz, darf aber nicht flüchtig sein.
  • Netzwerk: Portgeschwindigkeit und enthaltener Traffic müssen zum erwarteten Datenvolumen passen. Große Downloads und Mediendateien beeinflussen die Kosten stärker als die Zertifikatskommunikation.
  • IP-Adressen: Prüfe, ob IPv4 enthalten, kostenpflichtig oder gar nicht vorgesehen ist. Auch die Bereitstellung von IPv6 und Reverse-DNS kann je nach weiterem Einsatzzweck relevant sein.
  • Verwaltung: Ein Unmanaged-Tarif überlässt Updates, Absicherung, Monitoring und Wiederherstellung vollständig Dir. Bei einem Managed-Angebot muss die Leistungsbeschreibung ausdrücklich erkennen lassen, ob Caddy und die eigene Anwendung überhaupt betreut werden.

TLS-Zertifikate, die Caddy über eine öffentlich vertrauenswürdige Zertifizierungsstelle automatisiert bezieht, verursachen nicht automatisch eine separate Zertifikatsgebühr. Daraus folgt aber nicht, dass der gesamte HTTPS-Betrieb kostenlos ist: Domain, Server, Backups, IP-Optionen, Administrationszeit und gegebenenfalls Managed-Leistungen bleiben Kostenfaktoren.

Eine Monatsrechnung macht versteckte Aufpreise sichtbar

Für den Tarifvergleich kannst Du alle verpflichtenden Kosten auf einen effektiven Monatswert umrechnen. Dabei bezeichnet G den monatlichen Grundpreis, O die monatlichen Pflichtoptionen, E eine einmalige Einrichtungsgebühr und L den betrachteten Zeitraum in Monaten. Die Rechnung lautet:

Effektiver Monatswert = G + O + (E ÷ L)

Ein rein hypothetisches Beispiel: Ein VPS kostet 8 Euro pro Monat. Eine benötigte IP-Option kostet 1 Euro, ein Backup-Paket 2 Euro und für die Einrichtung werden einmalig 12 Euro berechnet. Bei einer Betrachtung über zwölf Monate ergibt sich:

8 Euro + (1 Euro + 2 Euro) + (12 Euro ÷ 12 Monate) = 12 Euro pro Monat

Der Zahlencheck passt: 8 Euro Grundpreis plus 3 Euro Optionen plus 1 Euro anteilige Einrichtung ergeben 12 Euro. Über zwölf Monate sind das 144 Euro. Dieses Rechenszenario ist keine Marktpreisangabe, sondern zeigt, warum ein beworbener Grundpreis von 8 Euro in diesem Aufbau nicht die tatsächliche Kostenbasis darstellt.

Bei Jahreszahlung gehört der vollständige Jahrespreis einschließlich verpflichtender Optionen in die Rechnung. Ein vorübergehender Rabatt sollte getrennt vom späteren Verlängerungspreis stehen. So wird sichtbar, ob der Tarif nur am Anfang günstiger ist oder auch über den vorgesehenen Betriebszeitraum passt.

Persistenter Speicher ist bei Containern unverzichtbar

Bei einer direkten Installation als Systemdienst liegt Caddys Datenbestand normalerweise in einem dafür vorgesehenen Systemverzeichnis. In einem Container muss dieses Verzeichnis dagegen ausdrücklich auf ein dauerhaftes Volume gelegt werden. Ohne persistente Einbindung können Zertifikate und Kontodaten beim Ersetzen des Containers verloren gehen.

Ein Verlust bedeutet nicht zwangsläufig einen dauerhaften Ausfall, weil Caddy Zertifikate erneut anfordern kann. Wiederholte Neuausstellungen sind dennoch unerwünscht und können an Begrenzungen der Zertifizierungsstelle stoßen. Außerdem gehört der private Schlüssel zum sicherungswürdigen Betriebszustand und sollte nicht bei jedem Deployment verschwinden.

Für eine Containerplanung sind daher mindestens zwei dauerhafte Bereiche sinnvoll: der Caddy-Datenspeicher für Zertifikate und Schlüssel sowie der Konfigurationsspeicher, sofern die Konfiguration nicht reproduzierbar aus einer Versionsverwaltung oder Deployment-Pipeline erzeugt wird. Sicherungen dieser Bereiche müssen geschützt sein, weil sie sensibles Schlüsselmaterial enthalten können.

Wann die Automatik zusätzliche Planung braucht

Ein einzelner Caddy-Server mit öffentlich erreichbarer Domain ist der einfachste Fall. Komplexer wird die Zertifikatsverwaltung bei mehreren Instanzen, privaten Diensten oder besonderen DNS-Anforderungen.

  • Mehrere Caddy-Instanzen: Unabhängige Server sollten nicht unkoordiniert Zertifikate für dieselben Namen anfordern. Bei Hochverfügbarkeit werden gemeinsamer Zustand, eine geeignete Speicherlösung oder eine klar definierte TLS-Terminierung benötigt.
  • Wildcard-Zertifikate: Zertifikate für sämtliche Subdomains einer Domain erfordern üblicherweise eine DNS-basierte Validierung. Dafür braucht Caddy ein zum DNS-Anbieter passendes Modul und sicher verwahrte Zugangsdaten.
  • Nicht öffentlich erreichbare Dienste: Für interne Hostnamen oder rein private Netze ist eine öffentliche Zertifikatsausstellung nicht immer möglich oder sinnvoll. Caddy kann eine interne Zertifizierungsstelle verwenden, deren Stammzertifikat auf den zugreifenden Geräten als vertrauenswürdig eingerichtet werden muss.
  • Vorgeschalteter Proxy: Beendet ein externer Dienst bereits die TLS-Verbindung, muss festgelegt werden, ob Caddy intern ebenfalls HTTPS verwendet oder nur unverschlüsselte Verbindungen in einem geschützten Netz annimmt. Doppelte, unklare Zertifikatsverwaltung erschwert die Fehlersuche.

Für einen einfachen VPS ist keine Clusterlösung erforderlich. Wer mehrere Instanzen für Ausfallsicherheit plant, sollte die Zertifikats- und Speicherarchitektur jedoch vor der Tarifauswahl festlegen. Der günstigste Einzelserver lässt sich nicht ohne Weiteres in einen hochverfügbaren Aufbau umwandeln.

Eine minimale Caddy-Konfiguration als Funktionsprüfung

Für eine Anwendung, die lokal auf Port 3000 lauscht, kann eine einfache Caddyfile-Konfiguration aus einem Domainblock und einer Reverse-Proxy-Anweisung bestehen. Mit dem Platzhalter example.org sieht die vollständige Minimalfassung so aus:

Vor der Verwendung muss example.org durch die eigene Domain ersetzt werden. Die Anwendung muss auf dem Server tatsächlich unter 127.0.0.1 und Port 3000 erreichbar sein. Nach dem Laden der Konfiguration sollte der Aufruf über HTTPS funktionieren, der Browser ein vertrauenswürdiges Zertifikat anzeigen und eine HTTP-Anfrage auf HTTPS weitergeleitet werden.

Schlägt die Ausstellung fehl, ist die Prüfreihenfolge eindeutig: Zuerst DNS-Ziel und öffentliche Erreichbarkeit von Port 80 und 443 kontrollieren, danach eine mögliche Portbelegung durch andere Dienste prüfen und erst anschließend die Caddy-Protokolle auswerten. Meldet Caddy dagegen einen Fehler zum internen Ziel, funktioniert die öffentliche TLS-Seite möglicherweise bereits, während die Anwendung hinter dem Reverse Proxy nicht erreichbar ist.

Da sich unterstützte Module und Konfigurationsdetails mit der eingesetzten Ausgabe unterscheiden können, solltest Du die installierte Caddy-Version feststellen und in der zugehörigen offiziellen Dokumentation die Bereiche Automatic HTTPS, Caddyfile und verwendete Direktiven prüfen. Das ist besonders wichtig, wenn DNS-Module, externe Speicheradapter oder eine angepasste Caddy-Binärdatei eingesetzt werden.

Die sinnvolle Entscheidung für den Serverbetrieb

Für eine statische Website oder eine kleine Anwendung ist meist ein schlanker VPS mit persistentem Speicher, sauber erreichbaren Webports und ausreichender RAM-Reserve die passende Ausgangsbasis. Mehr CPU, RAM oder dedizierte Hardware werden nicht durch die automatische Zertifikatsverwaltung nötig, sondern durch die Anwendung, Datenbank, Zahl der Dienste und erwartete Last.

Caddy vereinfacht den Betrieb vor allem dort, wo eine Person mehrere Domains oder kleine Anwendungen ohne separate Zertifikatswerkzeuge verwalten möchte. Der Tarif ist passend, wenn der reguläre Gesamtpreis alle benötigten IP-, Backup- und Verwaltungsoptionen enthält, die Ressourcen für den vollständigen Softwarestapel reichen und das Caddy-Datenverzeichnis dauerhaft gesichert werden kann. Fehlt eine dieser Voraussetzungen, löst auch die bequeme TLS-Automatik das eigentliche Betriebsrisiko nicht.

Checkliste
  • RAM: Entscheidend ist der Gesamtbedarf von Caddy, Anwendung, Datenbank, Betriebssystem und weiteren Diensten. Garantierter Arbeitsspeicher ist für einen dauerhaft betriebenen Webserver besser planbar als unklar beschriebener dynamischer Speicher.
  • CPU: Prüfe Anzahl und Art der vCPUs sowie mögliche Hinweise zur dauerhaften Auslastung. Kurzzeitige Spitzen und dauerhaft hohe Rechenlast sind tariflich nicht immer gleich behandelt.
  • Speicher: Neben der Kapazität zählen Speichertechnik, nutzbarer Platz und die Möglichkeit von Snapshots oder Backups. Das Caddy-Datenverzeichnis beansprucht wenig Platz, darf aber nicht flüchtig sein.
  • Netzwerk: Portgeschwindigkeit und enthaltener Traffic müssen zum erwarteten Datenvolumen passen. Große Downloads und Mediendateien beeinflussen die Kosten stärker als die Zertifikatskommunikation.
  • IP-Adressen: Prüfe, ob IPv4 enthalten, kostenpflichtig oder gar nicht vorgesehen ist. Auch die Bereitstellung von IPv6 und Reverse-DNS kann je nach weiterem Einsatzzweck relevant sein.
  • Verwaltung: Ein Unmanaged-Tarif überlässt Updates, Absicherung, Monitoring und Wiederherstellung vollständig Dir. Bei einem Managed-Angebot muss die Leistungsbeschreibung ausdrücklich erkennen lassen, ob Caddy und die eigene Anwendung überhaupt betreut werden.

Unsere Redaktion

Hinter server-preis.de steht eine Redaktion mit einem klaren Blick für Servertechnik, Leistungsdaten und faire Preisvergleiche. Wir bereiten technische Unterschiede so auf, dass Du Serverangebote besser einordnen und passend zu Deinem Vorhaben auswählen kannst.

Bernd Kammholz aus der Redaktion von server-preis.de

Bernd Kammholz

Bernd beschäftigt sich mit der verständlichen Einordnung von Serverangeboten, technischen Leistungswerten und laufenden Kosten. Sein Schwerpunkt liegt darauf, komplexe Tarifdetails nachvollziehbar gegenüberzustellen und wichtige Unterschiede zwischen den Angeboten sichtbar zu machen.

Frank Liefers aus der Redaktion von server-preis.de

Frank Liefers

Frank konzentriert sich auf Serverhardware, Konfigurationen und die technischen Anforderungen unterschiedlicher Projekte. Er achtet besonders darauf, ob Prozessor, Arbeitsspeicher, Speichertechnik und Netzwerkanbindung sinnvoll aufeinander abgestimmt sind.

Mark Hennings aus der Redaktion von server-preis.de

Mark Hennings

Mark befasst sich mit Serverbetrieb, Skalierbarkeit und der Auswahl passender Systeme für Webseiten, Anwendungen und datenintensive Projekte. In seinen Beiträgen verbindet er technische Kriterien mit der Frage, welche Lösung im praktischen Einsatz wirklich sinnvoll ist.

Schreibe einen Kommentar