Eigene technische Plattform · Kompetenzprojekt
Managed Self-Hosting – kontrollierbarer Betrieb statt Infrastruktur-Blackbox
Die Managed Self-Hosting Platform standardisiert, wie passende Wannsee.IT-Webprojekte gebaut, bereitgestellt und technisch betrieben werden. Sie ist kein eigenständiges SaaS-Produkt, sondern ein wiederverwendbares Betriebsmodell.
Ausgangssituation
Kleine Anwendungen brauchen keine Enterprise-Cloud – aber klaren Betrieb
Reproduzierbares Deployment, HTTPS, getrennte Anwendungen, Updates, Healthchecks und Wiederherstellbarkeit bleiben auch bei überschaubaren Projekten notwendig.
- kein zufälliger Codezustand auf dem Server
- keine unklaren öffentlichen Zugriffswege
- keine Verantwortungslücke nach der Entwicklung
Grundprinzip
Eine kleine standardisierte Betriebsplattform
Projekte werden nach denselben technischen Regeln gebaut und bereitgestellt. Die Plattform ersetzt keine projektspezifische Risiko- und Betriebsentscheidung.
- versionierter, freigegebener Stand
- isolierte Container und zentraler Zugriff
- Healthcheck vor erfolgreicher Auslieferung
Öffentliche Architektur
Vom freigegebenen Stand bis zum geprüften Webdienst
Die Darstellung bleibt bewusst abstrakt. Servernamen, IP-Adressen, Pfade, Netzwerkbezeichnungen, Auth-Konfiguration, Firewallregeln und konkrete Deployment-Skripte werden nicht veröffentlicht.
Git / Freigabe
Ein versionierter Stand bildet die Grundlage.
Reproduzierbarer Build
Code und Abhängigkeiten werden kontrolliert zusammengeführt.
Container Image
Der Anwendungscode wird als definierte Einheit bereitgestellt.
Proxy, Domain & TLS
Öffentlicher Zugriff wird zentral zugeordnet.
Healthcheck & Betrieb
Start allein gilt nicht als erfolgreiche Bereitstellung.
01 / PRINZIPIEN
Kleine Plattform, klare Regeln
Technische Verantwortung an wenigen Stellen bündeln
Keine Host-Port-Wildnis
Anwendungen laufen isoliert; der zentrale Proxy übernimmt den öffentlichen Zugriff.
TLS zentral
HTTPS und Zertifikate werden nicht pro Anwendung neu erfunden.
Code im Image
Produktiver Anwendungscode entspricht einem reproduzierbaren Build.
Mutable Daten getrennt
Nur notwendige Daten, Uploads und Dokumente werden persistent gehalten.
Non-Root
Anwendungen laufen ohne unnötige Systemrechte.
Healthcheck
Ein Dienst muss nach dem Start fachlich erreichbar sein.
DEV und PROD getrennt
Entwicklung und produktiver Betrieb haben unterschiedliche Verantwortlichkeiten.
Technologierahmen
Bewährte Bausteine statt proprietärer Plattformschicht
Hetzner Cloud, Ubuntu LTS, Docker Engine, Docker Compose, nginx als Reverse Proxy und Let's Encrypt bilden den öffentlich benennbaren Rahmen. Getrennte Entwicklungs- und Produktionsumgebungen, Healthchecks, Non-Root-Container und versionierte Deployments ergänzen das Modell.
Nicht öffentlich: konkrete Server, Adressen, Dateisystem- oder Backup-Pfade, Nutzerkennungen, interne Netze, Zugriffs- und Firewallkonfiguration sowie Wartungszeiten.
Warum Self-Hosting?
Eine Option, keine Ideologie
Self-Hosting kann passen, wenn eine individuelle Anwendung ohnehin betrieben werden muss, Datenflüsse kontrollierbar bleiben sollen und Architektur, Kosten sowie Verantwortlichkeiten überschaubar sind.
SaaS oder PaaS kann die bessere Lösung sein, wenn die Standardfunktion passt und eigener Betrieb keinen fachlichen Vorteil schafft. Vor der Entscheidung werden Schutzbedarf, Wiederherstellung und Zuständigkeiten geklärt.
Was Wannsee.IT übernimmt
Projektbezogener Betrieb ohne erfundene Pauschal-SLA
Der konkrete Leistungsumfang wird je Projekt vereinbart. Öffentliche Pauschalversprechen zu Verfügbarkeit oder Backupfristen werden nicht gemacht.
Bereitstellung
Technische Umgebung und reproduzierbarer Releaseweg.
Domain & TLS
Zuordnung und verschlüsselte Auslieferung.
Updates & Fehleranalyse
Pflege der verantworteten Komponenten und technische Diagnose.
Wiederherstellbarkeit
Version, Konfiguration und veränderliche Daten werden getrennt betrachtet.
Entwicklung und Betrieb zusammendenken
Der Betriebsweg beginnt nicht erst nach dem letzten Entwicklungstag
Bei passenden Projekten wird früh geklärt, wie veröffentlicht wird, welche Daten persistent sind, wie eine Version reproduziert und ein Fehler erkannt wird und welcher Rückfallweg besteht.
Betriebsmodell für eine Webanwendung besprechen