PRINZIP — CLOUD READY
Cloud Ready
Containerisiert und portabel von Tag eins — damit dich weder ein Cloud-Anbieter noch wir festhalten können. Cloud-Ready heißt: Die Cloud ist ein Werkzeug, kein Zwang.
Warum wir das so machen
Die Begründung.
Portabel heißt, dass die Software nicht an einen bestimmten Anbieter gekettet ist. Unsere eigenen Anwendungen laufen auf unserem Server in Wien; was wir für dich bauen, ist so gebaut, dass es unverändert bei einem europäischen Anbieter deiner Wahl oder in deinem Rechenzentrum läuft. Wir nennen es bewusst Cloud-Ready und nicht Cloud-only, weil die Entscheidung, wo etwas läuft, eine betriebswirtschaftliche und rechtliche ist — keine, die die Architektur vorwegnehmen sollte.
Der Nebeneffekt ist, dass Deployments langweilig werden, im besten Sinn. Wenn eine Anwendung samt ihren Abhängigkeiten in einem Container beschrieben ist, dann ist „läuft bei mir“ kein Argument mehr, und ein Umzug ist kein Projekt.
Ein Detail, das viel Ärger erspart: Datenbank-Migrationen laufen bei uns als eigener Vorlauf-Dienst, der abgeschlossen sein muss, bevor die Anwendung überhaupt startet. Damit kann die Anwendung gar nicht erst gegen ein nicht migriertes Schema hochkommen — ein Fehlerbild, das sonst gerne nachts um drei auftritt und schwer zu deuten ist.
Was du davon hast
Du bist nicht in einem Anbieter eingesperrt und nicht dessen Preiserhöhungen ausgeliefert. Du kannst in Österreich hosten, ohne auf einen US-Anbieter angewiesen zu sein — und den Betriebsort später wechseln, ohne die Software neu zu bauen.
Konkret
Die Entscheidungen dahinter.
Docker-first, überall
Jede Anwendung läuft containerisiert und reproduzierbar — jede Umgebung und jeder Dienst in einer Datei beschrieben statt händisch eingerichtet.
Migrationen vor dem Start
Ein eigener Vorlauf-Dienst führt Schema-Änderungen aus; die Anwendung startet erst danach. Kein Hochfahren gegen ein halb migriertes Schema.
Einrichtung, die man zweimal ausführen darf
Einrichtungsskripte überspringen, was schon getan ist, und überschreiben nie eine bestehende Konfiguration — ein zweiter Lauf bleibt folgenlos.
Reverse-Proxy mit automatischem TLS
Zertifikate werden automatisch geholt und erneuert, Sicherheits-Header zentral gesetzt. Kein manuelles Zertifikatsdatum im Kalender.
Wo es läuft, entscheidest du
Unsere eigenen Produkte betreiben wir auf unserem Server in einem Rechenzentrum in Wien. Was wir für dich bauen, läuft auf deinem Server oder auf einem, den du dafür bereitstellst — ohne dass die Software neu gebaut werden muss.
Sicherung nach dem 3-2-1-1-0-Grundsatz
Für die eigene Plattform festgelegt: eigener Sicherungsknoten plus Offsite-Kopie, die sich die Daten selbst abholt statt sie zugeschickt zu bekommen — mit getrennten Zugangsdaten, damit ein kompromittiertes Produktivsystem die Kopie nicht mitreißen kann. Die Null steht für: null Fehler bei der Prüfung.
Wiederherstellung ist ein Termin, kein Vorsatz
Für die eigene Plattform festgelegt, heute noch nicht im Betrieb: ein monatlicher automatischer Wiederherstellungstest mit signiertem Protokoll und eine Stichprobe aus der Offsite-Kopie. Eine Sicherung, aus der nie zurückgespielt wurde, ist eine Vermutung.
Belege
Woran du uns messen kannst.
- Eigener Server in einem Rechenzentrum in Wien, betrieben für Website, Mailserver und Geoplattform.
- RetterApp, Stand 16.08.2026: sieben Compose-Dateien beschreiben alle Umgebungen und Dienste — von Entwicklung bis Überwachung.
- Ein-Befehl-Deploys mit anschließender Prüfung, ob der Dienst danach wirklich antwortet — beim Internetauftritt von Lebensmittelrettung Österreich sind es 24 Aufrufe von außen nach jedem Ausrollen (Stand 03.09.2026).
- Härtungsindex des Produktivservers: 82 von 100 Punkten im automatisierten Lynis-Scan (Stand 24.06.2026).
Häufige Fragen
Was oft gefragt wird.
Was passiert, wenn wir irgendwann zu einem anderen Anbieter wollen?
Dann ziehst du um. Weil die Anwendung containerisiert und ihre Umgebung beschrieben ist, ist der Wechsel eine Betriebsaufgabe und kein Neubau.
Ist ein eigener Server nicht riskanter als eine große Cloud?
Er ist anders riskant. Eine große Cloud nimmt dir Redundanz ab und bindet dich dafür an einen Anbieter. Ein eigener Server verlangt Betriebsdisziplin: gehärtete Container, nächtliche verschlüsselte Sicherungen, Überwachung mit Lebenszeichen, dokumentierte Wiederanlauf-Abläufe. Was davon noch offen ist, steht bei den Grenzen auf dieser Seite.
Weiterlesen
Passt dazu.
Die anderen Prinzipien.
Jedes für sich erklärt, warum wir so bauen — und woran man es nachprüfen kann.