DevOps & CI/CD

Zwischen "wir kopieren per Hand auf den Server" und einem Kubernetes-Cluster mit eigenem Platform-Team liegt viel vernünftige Mitte – und genau dort laufen die meisten mittelständischen Softwaresysteme.

Ich baue Deploy-Pipelines in genau dieser Größe: automatisiert, nachvollziehbar, zurückrollbar – ohne Orchestrierungs-Overhead, den niemand im Haus betreiben kann.

Die Bausteine

Deploy-Pipelines mit klarer Regel

GitHub Actions mit einer Konvention, die jeder versteht: Push auf main deployt Staging, ein Versions-Tag deployt Produktion. Kein manuelles Kopieren, keine "Wer hat zuletzt was eingespielt?"-Fragen – die Pipeline ist die einzige Route auf den Server.

Container & Registry

Anwendungen als Docker-Images, versioniert in einer Container-Registry (z. B. GHCR). Jeder Produktionsstand ist ein unveränderliches, getaggtes Image – dasselbe Artefakt in Staging und Produktion, reproduzierbar gebaut aus dem Git-Stand.

Reverse Proxy & TLS

Traefik als zentraler Einstiegspunkt: Routing zu den Containern, automatische Zertifikate über Let's Encrypt, Middleware für Basic-Auth und Redirects. HTTPS ist Standard, nicht Projekt – und ein neuer Dienst ist eine Konfigurationszeile, kein Wochenend-Einsatz.

Secrets-Management

Keine Passwörter, Tokens oder Schlüssel im Repository – Secrets liegen in der Umgebung (CI-Secrets, zentrale Umgebungsdatei auf dem Server), Konfigurationsdateien enthalten nur Platzhalter. Und wenn ein Secret doch einmal im Klartext stand: rotieren, nicht hoffen.

Infrastruktur als versionierte Konfiguration

Compose-Stacks, Proxy-Regeln und Deploy-Skripte liegen im Git – der Server ist Abbild des Repositories, nicht umgekehrt. Rollouts laufen als nachvollziehbarer Workflow; bei Infrastruktur-Änderungen bleibt bewusst ein Mensch der Auslöser.

Backups & Rollback

Automatisierte, verschlüsselte Backups als eigener Stack – inklusive dokumentiertem Wiederherstellungs-Ablauf. Und für die Anwendung selbst: Rollback heißt, einen früheren Image-Tag erneut zu deployen – ohne Neubau, in Minuten.

Ich betreibe das selbst – jeden Tag

Die deho-Infrastruktur läuft exakt nach diesem Muster. Kein Referenzprojekt aus zweiter Hand, sondern mein eigener Betrieb:

  • GitHub Actions mit selbst gehostetem Runner: Build in der Cloud, Deploy durch einen Runner auf dem Zielsystem – kein von außen offener Deploy-Zugang
  • Push = Staging, Tag = Produktion: Jeder main-Stand landet automatisch auf einer Staging-Umgebung hinter Basic-Auth; Produktion wird ausschließlich über Versions-Tags deployt
  • Rollback per Tag-Deploy: Ein manuell auslösbarer Workflow deployt jeden bestehenden Image-Tag aus der Registry (GHCR) erneut auf Produktion – ohne Neubau
  • Smoke-Tests nach jedem Deploy: Die Pipeline prüft direkt auf dem Server, ob die Anwendung antwortet – bei Staging inklusive Nachweis, dass der Basic-Auth-Schutz aktiv ist; schlägt der Test fehl, liefert sie die Container-Logs gleich mit
  • Traefik mit Let's Encrypt: Zertifikatsausstellung und -erneuerung laufen automatisch; Routing und Middleware liegen als versionierte Konfiguration im Git
  • Backups mit Restore-Plan: Verschlüsselte automatische Sicherungen, inklusive dokumentierter Wiederherstellung und durchgeführter Schlüsselrotation – ein Backup zählt erst, wenn der Rückweg geprüft ist

Genau dieses Muster – angepasst an Ihre Systeme, Ihre Umgebung und Ihr Team – ist das, was ich bei Kunden aufbaue.

Passende Größe statt maximaler Ausbau

  • Kein Kubernetes um des Kubernetes willen: Für viele Systeme sind Docker Compose, ein Reverse Proxy und eine saubere Pipeline die richtige Betriebsgröße – wartbar von dem Team, das Sie tatsächlich haben
  • Ehrliche Grenze: Den Betrieb großer Kubernetes-Cluster-Landschaften biete ich nicht als Kernleistung an – wächst Ihr Bedarf dorthin, sage ich das offen und helfe bei Architektur und Auswahl, statt es selbst zu behaupten
  • Übergabe statt Abhängigkeit: Pipelines und Infrastruktur-Konfiguration liegen in Ihrem Repository und sind dokumentiert – Ihr Team kann sie ohne mich weiterbetreiben
  • Betrieb hört nicht beim Deploy auf: Logs, Metriken und Alarme gehören dazu – mehr dazu unter Monitoring & Observability

Und wenn die Pipeline steht, geht es ums Dranbleiben: Review von Änderungen, technische Leitplanken, kontrollierte Weiterentwicklung – siehe Execution Governance.

Wie kommt Ihr Code heute auf den Server?

Wenn die Antwort ein Bauchgefühl ist statt einer Pipeline, lohnt sich ein Gespräch –
unverbindlich und kostenfrei.

Unverbindlich sprechen (kostenfrei)