Wie beim Managed Cloud Server trennen wir sauber: die Hardware-Kosten laufen direkt bei Hetzner oder dem Anbieter deiner Wahl auf deinen Account, dazu kommt unsere Management Fee pro Server. Keine versteckten Aufschläge auf die Hardware-Rechnung. Ob dediziert oder virtuell günstiger ist, rechnen wir vorher für deine Last durch – inklusive Storage und Traffic, denn diese beiden Posten kippen den Vergleich häufiger als der Compute-Preis.
Managed Dedicated Server bei Hetzner: individuell konfiguriert, von uns betrieben
Bei planbarer Dauerlast hat dedizierte Hardware das deutlich bessere Preis-Leistungs-Verhältnis als eine vergleichbare Cloud-VM: echte Kerne statt geteilter Rechenzeit, Arbeitsspeicher und NVMe in Mengen, die als VM schnell unbezahlbar werden, und ein Festpreis statt einer Rechnung, die mit der Nutzung wächst. Den größten Teil dieser Maschinen betreiben wir bei Hetzner – individuell auf deine Last zugeschnitten statt aus einem Paketkatalog gewählt.
Der Haken ist nicht die Rechnung, sondern die Verantwortung. Auf Blech gehören die Platte, das DIMM und das Netzteil dir – und niemand schiebt dich weg, wenn eines davon ausfällt. Genau diesen Teil übernehmen wir: Abnahme neuer Maschinen, Temperatur- und Verbrauchsüberwachung, RAID- und SMART-Trends, Backups und ein Restore, den wir üben.
Dedizierte Server, Cloud-VMs und Hardware, die beim Kunden im Lager steht, betreiben wir dabei mit demselben Ansible, demselben Monitoring und derselben Backup-Strecke. Ob die Maschine im Rechenzentrum oder in einer Lagerhalle steht und wem sie gehört, spielt für den Betrieb keine Rolle – und der Anbieter ebenso wenig: Wenn Netzanbindung, Traffic-Bedarf oder Zielregion für einen anderen sprechen, betreiben wir dieselben Systeme auch bei Latitude, DataPacket oder in deinem eigenen Rack.
Hardware, die wir live betreiben
60 s
Takt, in dem jeder Hardware-Host Temperaturen, Leistungsaufnahme und Lüfterdrehzahlen meldet – in eine Zeitreihendatenbank, nicht in ein Logfile.
5 Server
in den Fulfillment-Centern eines Kunden in Europa und den USA – angebunden per Site-to-Site-VPN, verwaltet wie jede Maschine im Rechenzentrum.
2 Standorte
eigene Backup-Hardware mit S3-kompatiblem Objektspeicher. Wir sichern unsere Kunden auf eigene Maschinen statt in fremden Cloud-Speicher.
Wann Blech, wann VM?
Es ist kein Entweder-oder. Wir setzen dediziert dort ein, wo Dauerlast liegt, und virtuell dort, wo Geografie oder kurze Lebensdauer zählen. Für die Entscheidung sind vier Punkte ausschlaggebend:
Konstante statt schwankender Leistung. Dedizierte Kerne kennen keine Steal Time und keine lauten Nachbarn. Für Datenbanken und alles Latenz-Sensitive ist das der Hauptgrund, nicht der Preis.
Lokale NVMe statt Netzwerk-Storage. Keine IOPS-Kontingente und keine Storage-Rechnung, die mit der Nutzung mitwächst. Bei Backup- und Analytics-Last kippt genau dieser Posten den Vergleich.
Grobkörnige Skalierung. Wachstum passiert in Stufen: Statt zwei vCPUs nachzubuchen, wechselt man auf das nächste Modell. Wer von vornherein Luft einplant, erreicht diese Stufe selten.
Vorlaufzeit statt Elastizität. Bereitstellung dauert Stunden statt Sekunden, ein Hardwaretausch hat Vorlauf. Wer echte Lastspitzen fährt, kombiniert deshalb sinnvoll mit Cloud-VMs.
Den vollständigen Tausch – was man gewinnt und was man dafür wirklich übernimmt – haben wir in einem eigenen Artikel aufgeschrieben: Dedizierte Server statt VM.
Warum meist Hetzner – und wann ein anderer Anbieter
Für den größten Teil unserer dedizierten Maschinen sind die Dedicated Root Server von Hetzner die naheliegende Wahl: Das Preis-Leistungs-Verhältnis ist im europäischen Markt schwer zu schlagen, die Rechenzentren stehen in Deutschland und Finnland, und die Palette reicht von der kleinen Anwendungsmaschine bis zum Server mit mehreren hundert Gigabyte RAM. Individuell heißt dabei: Wir dimensionieren nach deiner Last – Kerne, RAM, NVMe-Kapazität, RAID-Level – statt eine Paketgröße zu wählen, die entweder zu klein oder zu teuer ist.
AX-Linie (AMD) und EX-Linie (Intel) für Anwendungs- und Datenbankserver: viele dedizierte Kerne, NVMe und RAM-Ausbau, der als VM unbezahlbar wäre. Hier liegen bei uns Datenbank-Primaries und Replicas, ClickHouse-Knoten und die Maschinen, auf denen komplette Data Warehouses laufen.
GEX-Linie für GPU-Last, etwa lokal betriebene Sprachmodelle, bei denen die Daten das Haus nicht verlassen sollen.
Serverbörse für gebrauchte Hardware zum Bruchteil des Preises. Genau hier zahlt sich unser Abnahme-Check unmittelbar aus: Betriebsstunden, Plattenverschleiß und ECC-Fehler entscheiden, ob eine Maschine angenommen wird oder zurückgeht.
Festgelegt sind wir darauf nicht. Geben Netzanbindung, Traffic-Volumen oder eine Zielregion außerhalb Europas den Ausschlag, betreiben wir dieselben Systeme bei Anbietern wie Latitude oder DataPacket – oder auf Hardware, die dir selbst gehört. Getauscht wird der Unterbau, nicht die Betriebsweise: dieselben Playbooks, dasselbe Monitoring, dieselbe Backup-Strecke.
Ein Punkt, der die Rechnung zuletzt verschoben hat: Die Preise für Cloud-Server sind zum 15. Juni 2026 gestiegen, bei den Instanzen mit dedizierten vCPUs teils auf mehr als das Doppelte, und gerade die günstigen geteilten Größen sind in den meisten Standorten zeitweise kaum verfügbar. Bevor du den höheren Preis für eine Cloud-VM mit dedizierter CPU zahlst, lohnt der direkte Vergleich mit einer eigenen Maschine – bei Dauerlast kippt er häufiger zugunsten von Blech, als man erwartet. Wir rechnen das vorher durch, statt es zu behaupten.
Was wir auf dedizierter Hardware betreiben
Datenbank-Cluster mit großem Buffer-Pool, Primary und Replica auf getrennten Maschinen. Dedizierte ClickHouse-Server für analytische Abfragen, dazu Elasticsearch. Komplette Data-Warehouse-Server samt Ingestion und Dashboards. Objektspeicher für Backups. GPU-Hosts für lokale Sprachmodelle. Und Anwendungen mit harten Performance-Anforderungen, die konstante Antwortzeiten brauchen statt Burst-Guthaben. Wo sehr viele Requests pro Sekunde auflaufen, holen wir mit Kernel- und Netzwerk-Tuning heraus, was die Standardeinstellungen liegen lassen: Datei- und Socket-Limits, Netzwerk-Puffer, Connection-Backlogs, TCP- und Scheduler-Parameter. Auf einer VM endet dieser Weg dort, wo der Hypervisor anfängt. Wie wir darauf unsere eigene S3-kompatible Speicher-Infrastruktur betreiben, steht in einem eigenen Artikel.
Auch Hardware, die nicht im Rechenzentrum steht, gehört dazu: Server in Lagerhallen und Fulfillment-Centern, die weiterlaufen müssen, wenn die Leitung nach draußen ausfällt. Sie hängen an denselben Playbooks, schicken ihre Logs zentral heraus und melden Temperaturen und Lüfterdrehzahlen wie jede andere Maschine – ein Lager ist schließlich kein Rechenzentrum.
Wie wir die Hardware im Griff behalten
Eine VM hat dir noch nie von einem Lüfter erzählt. Auf Blech ist genau das der Unterschied zwischen einer guten und einer leichtsinnigen Entscheidung – deshalb machen wir die Hardware sichtbar, statt auf sie zu vertrauen.
Abnahme vor der Inbetriebnahme. Bevor eine Maschine in Produktion geht, prüfen wir Speicherbestückung und ob ECC wirklich aktiv ist, die ECC-Fehlerzähler, SMART-Werte pro Platte, Betriebsstunden und RAID-Status. Das Ergebnis ist ein Urteil in drei Stufen – bis hin zu „nicht abnehmen“.
Sensorik im Minutentakt. Temperaturen nach Quelle getrennt, Leistungsaufnahme in Watt, Lüfterdrehzahlen – aus IPMI, lm-sensors, SMART und RAID-Controller, je nachdem, was die Maschine hergibt. Ein Server, der bei gleicher Last mehr zieht, meldet sein Problem, bevor ein Prozess langsamer wird.
Alarmierung und Trends getrennt. Grafana zeigt den Verlauf über Wochen, Icinga2 weckt jemanden. SMART-Trends statt Momentaufnahmen, damit eine Platte auffällt, bevor sie ausfällt.
Reproduzierbarkeit statt Snapshot. Jeder Host ist vollständig in Ansible beschrieben, Backups laufen mit restic auf eigene Infrastruktur. Ein Neuaufbau ist damit ein Playbook-Lauf und kein Drama.
Wie das im Detail aussieht – inklusive der Werte, die ein Abnahme-Check bei gebrauchter Hardware zutage fördert – steht in unserem Artikel zu dedizierten Servern.
FAQ zu Managed Dedicated Servern
Was kostet ein Managed Dedicated Server?
Betreibt ihr Dedicated Server nur bei Hetzner?
Nein. Der größte Teil unserer Maschinen steht bei Hetzner, weil dort Preis-Leistung und die Standorte in Deutschland und Finnland für die meisten Anforderungen passen. Sprechen Netzanbindung, Traffic-Volumen oder eine Region außerhalb Europas dagegen, arbeiten wir genauso mit Anbietern wie Latitude oder DataPacket – oder mit Hardware, die in deinem eigenen Rack steht. Am Betrieb ändert das nichts: dieselben Playbooks, dasselbe Monitoring, dieselbe Backup-Strecke.
Und wenn eine Platte stirbt?
Sie stirbt irgendwann – deshalb RAID, SMART-Trends statt Momentaufnahmen und Backups außer Haus. Die Frage ist nicht, ob eine Platte ausfällt, sondern ob man es vorher sieht und ob der Wiederanlauf geübt ist. Fernwartung läuft über BMC beziehungsweise iLO und Rescue-System, den physischen Tausch übernimmt der Anbieter vor Ort.
Könnt ihr auch gebrauchte Hardware übernehmen?
Ja, und genau dafür gibt es unseren Abnahme-Check. Betriebsstunden, Verschleiß der Platten, ECC-Fehlerzähler und ein Selbsttest, der nie gelaufen ist – wenn das Bild nicht stimmt, wird die Maschine nicht angenommen. Gerade bei Auktions- und Börsen-Hardware ist das der Unterschied zwischen einem guten Preis und einem teuren Fehler.
Ohne Snapshots – wie rollt ihr Änderungen zurück?
Über zwei Wege, die zusammen mehr abdecken als ein Snapshot: Jeder Host ist vollständig in Ansible beschrieben, ein Neuaufbau ist also ein Playbook-Lauf. Und Daten kommen aus dem Backup zurück. Ein Snapshot rettet dich vor deinem eigenen Fehler, nicht vor einem Hardwareschaden – dafür brauchst du ohnehin ein Backup.
Betreut ihr auch Server, die bei uns vor Ort stehen?
Ja. Wir betreuen unter anderem Maschinen in Fulfillment-Centern in Europa und den USA, angebunden per Site-to-Site-VPN und verwaltet mit denselben Playbooks wie alles im Rechenzentrum. Vorab zu klären sind zwei Dinge: Ersatzteile vor Ort und eine klare Zuständigkeit für den Handgriff an der Maschine.
Sind wir zu klein für eigene Server?
Meist ist es andersherum. Eine Datenbank, die rund um die Uhr dieselbe Grundlast fährt, rechnet sich auf eigener Hardware oft schon ab der ersten Maschine. Elastizität zahlt sich nur aus, wenn man sie wirklich nutzt; wer rund um die Uhr dieselbe Grundlast fährt, zahlt in der Cloud für eine Flexibilität, die er nie abruft.
Lass uns deine Last durchrechnen
Wir schauen uns an, was du fährst, und sagen dir ehrlich in beide Richtungen, ob dediziert, virtuell oder eine Mischung passt. Kommt dediziert infrage, übernehmen wir Auswahl, Abnahme, Einrichtung und den laufenden Betrieb – mit Monitoring, Backup und 24/7-Bereitschaft per Slack. Schreib uns oder buche direkt ein kostenloses Erstgespräch.
Kontakt und Erstgespräch
Melde Dich gerne zu einem unverbindlichen Gespräch bei uns. Du kannst hier ein kostenloses, 15-minütiges Erstberatungsgespräch buchen oder einfach Kontakt auf einem dieser Kanäle aufnehmen.