Roadmap Aktualisiert am 10. Oktober 2026

Was Sarpius gerade baut, und in welcher Reihenfolge

Sarpius fehlen kaum noch Funktionen. Was fehlt, ist Beweis: Wiederherstellung, die nachweislich getestet statt nur versprochen wurde, und Produktionszahlen, die du selbst nachrechnen kannst. Die Datenbank-Wiederherstellung steht; als Nächstes öffnen wir, was wir selbst schon betreiben, dann folgt der Rest der Wiederherstellung und danach die Compute-Linie. Diese Seite nennt auch die Stellen, an denen wir heute zu kurz kommen.

In Arbeit Als Nächstes Geplant

Wo wir heute stehen

Deploys, Routing mit automatischem TLS, verwaltete Datenbanken (bei jeder dedizierten mit TLS), Objektspeicher mit öffentlichen Buckets, Message Queues, ein Edge-Cache, geplante Jobs und Abrechnung pro Minute laufen in Produktion, ebenso eine öffentliche Statusseite mit Verfügbarkeit und Vorfallshistorie pro Komponente. Sarpius Functions läuft in der geschlossenen Beta: Node.js, Python und PHP, pro Anfrage oder nach Zeitplan, abgerechnet pro GiB-Sekunde und pro Aufruf. Der gesamte Lebenszyklus einer Anwendung ist über die Konsole, die öffentliche API und einen MCP-Server für KI-Agenten steuerbar, und ein Projekt lässt sich als Migrationsbündel exportieren, wenn du gehen willst. SparxLite läuft heute, noch mit festen Größen, wobei jede Größe und ihr Preis veröffentlicht ist. Wiederherstellungspunkte, die du selbst zurückspielst, laufen für PostgreSQL (geteilt und dediziert) sowie für dediziertes Redis und MariaDB; dediziertes PostgreSQL 16 hat außerdem Point-in-Time Recovery.

Was in dieser Liste fehlt: Umgebungsvariablen und Datenbankverbindungen für Functions, Secrets-Verwaltung für deine eigenen Anwendungen, Wiederherstellungspunkte für Buckets und ein zweiter unabhängiger Standort. Das sind unten die Phasen 1, 2, 3 und 7, und bis es sie gibt, sagen wir pro Ressourcentyp genau, was wiederhergestellt wird und was nicht.

0 In Arbeit diesen Monat

Die restlichen Zahlen nach vorne

Verfügbarkeit pro Komponente, der zugehörige Messzeitraum und die Preise jeder SparxLite-Größe stehen bereits ohne Klick auf der Seite. Drei Zahlen fehlen noch oder stehen noch hinter einem Link.

Wiederherstellungszeit und Deploy-Erfolg auf der Statusseite. Mittlere Wiederherstellungszeit pro Komponente und der Anteil erfolgreicher Deployments, neben der Verfügbarkeit, die schon dort steht.
Die SLA dort, wo die Frage aufkommt. Bei Preisen, Datenbanken und Autoscaling eine kurze Zusammenfassung des Verfügbarkeitsziels und der Reaktionszeiten, mit Link zum vollständigen Dokument. Ein Ziel, keine Garantie, und das sagen wir dazu.
Wiederherstellungsgrenzen für jeden Ressourcentyp. Für Datenbanken heute veröffentlicht. Buckets, Apps und SparxLite folgen: was wiederhergestellt wird, wie viele Daten du schlimmstenfalls verlierst und wer die Aktion startet, auch dort, wo die Antwort ungünstig ausfällt.

Der Maßstab, den wir uns selbst setzen: Du kannst dein eigenes Risiko und deine eigene Rechnung einschätzen, ohne uns zu mailen. „Das wissen wir nicht“ ist nirgendwo mehr die faktische Antwort.

1 In Arbeit

Sarpius Functions, raus aus der geschlossenen Beta

Functions laufen bereits in deinem Projekt, in Firecracker-microVMs, mit eigenem Routing, eigenen Mitgliedern und eigener Abrechnung. In der geschlossenen Beta bleiben sie, weil sie den Rest deiner Anwendung noch nicht erreichen können.

Umgebungsvariablen pro Umgebung. Einstellbar auf dieselbe Weise wie bei jeder anderen Komponente.
Datenbankverbindungen. Verknüpfe eine Datenbank mit einer Function genau so, wie du sie heute mit einer App verknüpfst.
Offen für alle. Kein Beta-Zugang nötig, mit denselben Preisen pro GiB-Sekunde und pro Aufruf und denselben Ausgabenlimits.

Bis dahin ist Functions überall, wo wir es erwähnen, als geschlossene Beta gekennzeichnet. Dieselbe Regel gilt für alles auf der Seite: live, Beta oder geplant, nie nur angedeutet.

2 In Arbeit

SarpiVault, Secrets außerhalb deiner Umgebungsvariablen

SarpiVault verwahrt bereits die eigenen Secrets der Plattform, mit Versionierung und Audit-Trail. Der nächste Schritt ist, es für deine eigenen Anwendungen zu öffnen.

Versionshistorie pro Secret. Einschließlich wer was wann gelesen hat.
Injektion ohne Offenlegung. In Komponenten und Functions, ohne dass der Wert je in einer API-Antwort, einem Log oder einem Diff auftaucht.
Rotation ohne vollständigen Redeploy. Von allem, was den Schlüssel verwendet.

Warum vor dem Rest der Wiederherstellung: Ein Backup eines Systems, das Secrets noch als reine Umgebungsvariablen speichert, sichert diese Secrets gleich mit. Den Tresor zuerst für unsere eigenen Secrets zu betreiben ist, wie wir wissen, dass er hält, bevor wir dich bitten, ihm deine anzuvertrauen.

3 Geplant

Backup und Restore als Produkt

Wiederherstellungspunkte, die du selbst aus der Konsole zurückspielst, ohne Ticket und mit veröffentlichter Aufbewahrungsdauer, gibt es bereits für PostgreSQL (geteilt und dediziert) sowie für dediziertes Redis und MariaDB; dediziertes PostgreSQL 16 stellt über Point-in-Time Recovery außerdem auf jeden Zeitpunkt der letzten 7 Tage wieder her. Was hier noch bleibt, ist der Rest: Abdeckung für jeden Ressourcentyp und eine regelmäßige Prüfung, dass es wirklich funktioniert.

Wiederherstellungspunkte für Buckets. Derselbe Knopf wie bei den Datenbanken, die ihn schon haben.
RPO- und RTO-Ziele pro Ressourcentyp. Öffentlich.
Ein automatisierter Wiederherstellungstest. Läuft nach Zeitplan, mit einem Ergebnis, das du sehen kannst.

Dieser letzte Punkt ist nicht optional. Ein Backup, von dem noch nie wiederhergestellt wurde, ist eine Annahme. Das kommt bewusst vor der Compute-Phase: SparxLite und SparxCore docken hier an, statt jeweils ihre eigene halbe Lösung zu bekommen.

4 Geplant

Managed Domains, deine Domain ohne DNS-Handarbeit

Heute kaufst du eine Domain woanders und richtest die Records danach selbst ein. Das wird ein Schritt innerhalb deines Projekts.

Registrieren und umziehen über Sarpius. Eine neue Domain kaufen, oder eine bestehende Domain mit einem Transfer-Code umziehen, bezahlt aus demselben Guthaben wie alles andere.
DNS bei uns gehostet. Records verwaltest du in der Konsole und über die API, mit denselben Rechten wie der Rest deines Projekts.
Automatisch mit deiner App verbunden. Eine Domain für eine Komponente auszuwählen reicht: Routing und TLS-Zertifikat übernehmen wir, ohne dass du irgendwo einen CNAME abtippen musst.
Kein Lock-in. Den Transfer-Code forderst du selbst in der Konsole an, ohne Ticket. Deine Domain gehört dir, auch wenn du gehst.

Warum nach den Backups und vor Compute: Eine Domain ist das Erste, worauf sich eine App stützt, und das Letzte, das du verlieren willst. Das braucht zuerst eine Plattform, deren eigene Wiederherstellung in Ordnung ist; jede Compute-Form, die danach kommt, bekommt das von Anfang an mit.

5 Geplant Neues Produkt

SparxLite neu gebaut, und SparxCore daneben

Die gesamte Compute-Linie wird in einem Zug in Ordnung gebracht. SparxLite wechselt von festen Größen zu freier Größenwahl, und SparxCore kommt dazu: vollwertige Cloud-VMs mit eigenem Kernel und Root-Zugriff.

Was es ist	SparxLite	SparxCore
Was es ist	Container	Vollwertige Cloud-VMs
Isolation	Geteilter Kernel	Eigener Kernel und eigenes OS
Zugriff	Verwaltet über die Konsole	Root über SSH, plus eine Notfallkonsole
Heute	Live, mit festen Größen	Noch nicht verfügbar

Freie Größenwahl. CPU, RAM und Speicher unabhängig einstellbar bei der Erstellung und beim Resize, statt eine feste Stufe zu wählen.
Ein öffentlicher Konfigurator. Du rechnest ohne Konto konkrete monatliche Kosten für 24/7-Betrieb aus, und das ist derselbe Betrag, der dir danach berechnet wird.
Die technischen Rahmenbedingungen veröffentlicht. CPU-Modell, geteilt oder dediziert, Fair Use, TCP und UDP, Ports pro Instanz, inklusive Bandbreite und was oberhalb dieser Grenze passiert.
DDoS-Schutzumfang für direkten Spielverkehr. Separat benannt, nicht nur für Webverkehr hinter dem Router.
SparxCore vollständig ab Tag eins. Erstellen, starten, stoppen, neu starten, Größe ändern, löschen, plus Konsolenzugriff, wenn das Netzwerk weg ist. Eine veröffentlichte Image-Liste, IPv4 und IPv6, und Firewallregeln aus der Konsole.
Snapshots und Backups aus Phase 3. Dieselbe Aufbewahrungsdauer und derselbe Wiederherstellungsknopf wie im Rest der Plattform, kein zweites System.
Was mit deinen Daten bei einem Hostausfall passiert. Pro Speichertyp veröffentlicht. Das ist die Frage, bei der VM-Käufer nachhaken, und das zu Recht.
SparxLite, SparxCore oder ein Projekt. Ein Vergleich, der sagt, wann du welches wählst, einschließlich wie es sich zu klassischem Game-Hosting und zu einem gewöhnlichen VPS verhält.

Bist du heute auf einer festen SparxLite-Größe: Wir legen fest, was mit deinem Preis passiert, sobald freie Größenwahl live geht, bevor sie live geht. Nicht danach.

6 Geplant

Kundenfälle mit echten Zahlen

Kein Testimonial, das sagt, dass es großartig funktioniert, sondern eine Produktionsumgebung, die du nachrechnen kannst.

Pro Fall verpflichtend: Anzahl der Komponenten und ihre Rolle, Requests pro Monat, Datenbankgröße und Engine, Deploy-Häufigkeit und ob diese Deploys Downtime hatten.
Ein echter Scaling-Fall. Von wie vielen zu wie vielen Replicas, und wodurch es ausgelöst wurde.
Mindestens ein Vorfall pro Fall. Was schiefging und wie lange die Wiederherstellung dauerte. Ein Fall ohne Störung ist kein Fall, das ist Werbung.
Ein echter Wiederherstellungsfall. Plus Aufnahmen eines Deploys, eines Rollbacks, Autoscaling in Aktion, und ein Export, der zeigt, dass du auch wieder rauskommst.

Diese Phase steht bewusst nach Phase 3. Der Wiederherstellungsfall ist der Teil, den ein technischer Leser am schärfsten prüft, und den konnten wir bis dahin nicht ehrlich machen.

7 Geplant

Eine zweite unabhängige Zone

Zuerst eine zweite, gut entworfene niederländische Zone. Erst danach mehrere Länder. Zwei Standorte auf denselben zugrunde liegenden Abhängigkeiten sind keine Redundanz, das ist eine Landkarte.

Zwei getrennte Standorte. Physisch und operativ, ohne gemeinsamen Strom, Netzwerk oder Speicher.
Datenbank-Failover. Zwischen beiden Standorten.
Routing, das einen ganzen Standort umgehen kann. Auch bei einem vollständigen Ausfall eines Standorts, nicht nur eines einzelnen Node.
Ein explizites Zonenversprechen für SparxCore-VMs. Beim Release von SparxCore festgelegt, statt es danach herumzubauen.
Ein durchgeführter Failover-Test mit veröffentlichtem Ergebnis. Sonst ist es ein Entwurf, keine Zone.

Internationale Regionen kommen danach, und dann aus vier konkreten Gründen: Latenz außerhalb der Niederlande, Wahlmöglichkeit bei der Datenresidenz, regionale Notfallwiederherstellung, und Kunden, die keine Abhängigkeit von einem einzelnen Land akzeptieren.

Laufend, neben jeder Phase

Die nummerierten Phasen sind eine Reihenfolge: Jede hat einen Grund, nach der vorherigen zu kommen. Diese beiden Stränge sind das nicht. Sie laufen ab jetzt mit, haben kein Enddatum und warten nicht auf Phase 7.

Mehr Frameworks, Runtimes und Integrationen

Die Arbeit, die die Plattform für mehr Menschen nutzbar macht: mehr Frameworks, die der Wizard erkennt, sobald du dein Repository verbindest, mehr Runtimes und Versionen, mehr Datenbank-Engines und mehr fertige Vorlagen.

Eine öffentliche Liste unterstützter Frameworks, Runtimes und Versionen, jeweils mit einem ehrlichen Status: getestet, experimentell oder geplant.
Die Aufnahmeregel: Etwas kommt erst auf diese Liste, wenn ein echtes Repository davon erkannt, gebaut und deployt wurde und dieser Deploy läuft. Nicht, wenn die Erkennung funktioniert und der Rest unerprobt ist.
Von Anfang an richtig eingerichtet: die Umgebungsvariablen und Ports, die ein Framework braucht, ohne dass du sie nachschlägst.
Anfragen über Discord. Was du anfragst, landet als geplant auf derselben öffentlichen Liste, sodass du verfolgen kannst, was damit passiert.

Auffindbarkeit und Transparenz

Kleine Arbeit, kumulativer Effekt.

Die vollständige öffentliche Erfahrung in jeder Sprache, die wir anbieten, heute Englisch, Niederländisch, Deutsch und Französisch, vollständig gehalten, wenn Seiten hinzukommen.
Jede Funktion gekennzeichnet als live, Beta oder geplant.
Eine öffentliche Architektur- und Sicherheitsseite.
Der Auftragsverarbeitungsvertrag und die Unterauftragsverarbeiterliste innerhalb von zwei Klicks von jeder Seite aus.
Eine Zusammenfassung eines unabhängigen Sicherheitsreviews.
Case Studies in der Hauptnavigation, neben dem Changelog und dieser Roadmap.

Wo wir heute zu kurz kommen

Das sind keine Präsentationsprobleme. Sie stehen hier, damit du sie kennst, bevor du eine Produktionsumgebung bei uns aufsetzt, und nicht danach.

Die Wiederherstellung ist noch nicht vollständig

Wiederherstellungspunkte, die du selbst zurückspielst, gibt es für PostgreSQL (geteilt und dediziert) sowie für dediziertes Redis und MariaDB, und dediziertes PostgreSQL 16 hat außerdem Point-in-Time Recovery. Wiederherstellungspunkte für Buckets gibt es noch nicht. Für alles, was noch nicht abgedeckt ist, pflege einen eigenen Export.

Wird in Phase 3 gelöst

Alles läuft in einer einzigen Fehlerdomäne

Die Plattform läuft heute an einem einzigen Standort. Ein Ausfall, der diesen Standort komplett trifft, trifft auch deine Anwendung. Das sagen wir lieber hier, als dass du es selbst herausfindest.

Wird in Phase 7 gelöst

SparxLite kennt nur feste Größen

Heute wählst du aus einer Reihe vordefinierter Größen. Passt deine Last in keine davon sauber hinein, zahlst du für eine Stufe, die du nicht brauchst. Jede Größe und ihr Monatspreis stehen auf der SparxLite-Seite, damit du zumindest nachrechnen kannst.

Wird in Phase 5 gelöst

Unsere Messhistorie ist noch kurz

Die Statusseite misst erst seit kurzer Zeit. Da lässt sich wenig beschleunigen; was wir stattdessen tun, ist ehrlich über den Zeitraum zu sein und jeden Vorfall öffentlich aufzuschreiben, einschließlich dem, was er uns gelehrt hat.

Wächst mit der Zeit

Ein Jahr ehrliche Statushistorie mit ein paar gut gehandhabten Ausfällen überzeugt mehr als eine theoretische 100 Prozent. Diese Roadmap ist der Weg dorthin, und sie wird aktualisiert, wenn sich die Reihenfolge ändert, statt mit einer zweiten ergänzt zu werden.

Statusseite ansehen Framework auf Discord anfragen