Tech USP: Updates sind keine Überraschung. Ihr setzt das Fenster wann gewartet werden darf, wir patchen Sicherheits-Probleme ohne euch zu belästigen, große Änderungen kommen mit langem Vorlauf und ihr entscheidet wann.
Sicht des Käufers: „Ein Tool-Update hat unsere interne App am Dienstag um 11:00 lahmgelegt — das ganze Lager hat aufgehört zu scannen.” — genau das ist das Failure-Pattern. Kumikos Antwort: Ihr setzt das Fenster, wir schieben nie Major-Änderungen während eurer Hauptzeit, und Sicherheits-Patches gehen raus bevor jemand sie ausnutzt.
Drei Arten von Updates, drei Regeln
Sicherheits-Patches. Wir beobachten den CVE-Feed für die Komponenten, von denen eure App abhängt. Wenn was Ernstes auftaucht, patchen wir das für euch — typischerweise innerhalb eines Tages nach Bekanntwerden. Ihr müsst nichts tun. Ihr bekommt eine Notification nachdem es passiert ist, mit einer Ein-Zeilen-Zusammenfassung was gefixt wurde.
Warum Force-Patches bei Sicherheit? Weil „wir patchen wenn’s passt” der Weg ist auf dem Sicherheitsvorfälle entstehen. Die Alternative — ihr trackt CVEs für Postgres, Bun, Redis, Node, eure Dependencies — ist genau der Aufwand, den ihr uns abgeben wollt.
Minor-Updates (neue Features, interne Verbesserungen). Werden bis zu eurem Wartungsfenster zurückgehalten. Default ist „Mo–Fr, 02:00–04:00 in eurer Zeitzone” — ihr könnt das in den Account-Einstellungen ändern oder einen spezifischen Wochen-Slot wählen. Ganze Monate könnt ihr als Freeze markieren (Black Friday, Weihnachten, eure Hauptsaison) und wir halten Updates zurück bis der Freeze vorbei ist.
Major-Updates (alles was ändert wie das System funktioniert). Opt-in, auf eurem Zeitplan. Die alte Version bleibt 6 Monate als Komfort-Fenster verfügbar — ihr migriert wenn ihr bereit seid, nicht wenn wir releasen. Wir sagen euch was sich ändert, was zu testen ist, und sind auf Zuruf dabei wenn ihr’s braucht.
Schrittweiser Rollout — nie alle gleichzeitig
Wenn wir ein Update ausrollen, ist eure App nicht im ersten Batch. Updates gehen schrittweise raus:
- Erst auf interne Test-Instanzen.
- Dann eine kleine Gruppe Pilot-Kunden.
- Die nächste Gruppe, nachdem wir eine Weile beobachtet haben.
- Dann alle anderen.
Zwischen den Schritten warten wir. Wenn Fehlerraten steigen oder was komisch aussieht, halten wir den Rollout an — die Phase in der ihr seid, entscheidet ob ihr betroffen seid. Die meisten Probleme werden gefangen bevor sie die Mehrheit der Kunden treffen.
Hochverfügbarkeit für Apps die sie wirklich brauchen
Standard-Verhalten auf einem Standard-Tier: Ein Update bedeutet einen kurzen Neustart, in der Größenordnung von wenigen Sekunden. Für 95% interner Tools ist das unsichtbar — User lädt neu, Seite ist wieder da.
Für Apps die wirklich keine Sekunde Ausfall vertragen — öffentliche Statuspages, Echtzeit-Steuerungs-Tools — gibt es einen Hochverfügbarkeits-Modus der eure App parallel laufen lässt während des Updates. Alte Version bleibt online während die neue hochkommt, Traffic switcht ohne einen Request fallen zu lassen. Verfügbar ab Pro, fragt uns an wenn ihr’s braucht.
Was ihr steuert
| Einstellung | Was sie tut |
|---|---|
| Wartungsfenster | Wochentag + Uhrzeit in eurer Zeitzone |
| Freeze-Monate | Monate markieren in denen keine nicht-kritischen Updates rausgehen (Hauptsaison, Black Friday, Audit-Vorbereitung) |
| Jetzt-Updaten-Button | Wollt ihr nicht aufs Fenster warten? Nächstes ausstehendes Update auf Knopfdruck triggern |
| Benachrichtigungs-Kanal | E-Mail, Slack, Webhook — eure Wahl |
| HA-Modus (Pro+) | Update ohne Neustart wenn ihr’s einschaltet |
Was wir nicht machen
Wir schieben keine Major-Änderungen während eurer Hauptsaison. Wir überraschen euch nicht mit Breaking-API-Changes. Wir updaten nicht am Dienstag um 11:00 „weil unser Deploy gerade durchgelaufen ist”. Wir lassen euch nicht um 03:00 morgens nach CVEs in eurem Stack googlen weil was zusammengebrochen ist.
Die Kontrolle gehört euch. Die Arbeit gehört uns.