Roadmap Updated 10 October 2026

What Sarpius is building, and in what order

Sarpius is hardly missing features any more. What it is missing is proof: recovery that has demonstrably been tested rather than promised, and production numbers you can check for yourself. Database recovery is in place; what follows is opening up what we already run for ourselves, then the rest of recovery, then the compute line. This page also names the places where we fall short today.

In progress Up next Planned

Where we are today

Deploys, routing with automatic TLS, managed databases (with TLS on every dedicated one), object storage with public buckets, message queues, an edge cache, scheduled jobs and per-minute billing all run in production, as does a public status page with per-component uptime and incident history. Sarpius Functions runs in closed beta: Node.js, Python and PHP, per request or on a schedule, billed per GiB-second and per invocation. The full lifecycle of an application is driveable from the console, the public API and an MCP server for AI agents, and a Project can be exported as a migration bundle whenever you want to leave. SparxLite runs today, still on fixed sizes, with every size and its price published. Restore points you put back yourself run for PostgreSQL (shared and dedicated), and dedicated Redis and MariaDB; dedicated PostgreSQL 16 also has point-in-time recovery.

What is not in that list: environment variables and database connections for Functions, secrets management for your own applications, restore points for buckets, and a second independent location. Those are phases 1, 2, 3 and 7 below, and until they exist we state per resource type exactly what does and does not get restored.

0 In progress this month

The remaining numbers, up front

Uptime per component, the measurement window it covers and the prices of every SparxLite size are already on the site without a click. Three numbers are still missing, or still sit behind a link.

Recovery time and deploy success on the status page. Mean time to recovery per component and the share of deploys that succeeded, next to the uptime that is already there.
The SLA where the question comes up. On pricing, databases and autoscaling, a short summary of the availability target and response times, linking to the full document. A target, not a guarantee, and we say so.
Recovery limits for every resource type. Published for databases today. Buckets, apps and SparxLite follow: what gets restored, how much data you can lose at worst, and who starts the action, including where the answer is unfavourable.

The test we hold ourselves to: you can assess your own risk and your own bill without emailing us. "We do not know" stops being the factual answer anywhere.

1 In progress

Sarpius Functions, out of closed beta

Functions already run inside your Project, in Firecracker microVMs, with their own routing, members and billing. What keeps them in closed beta is that they cannot yet reach the rest of your application.

Environment variables per environment. Set the same way as for any other component.
Database connections. Link a database to a function exactly as you link it to an app today.
Open to everyone. No beta access needed, with the same per-GiB-second and per-invocation prices and the same spending caps.

Until then, Functions is marked closed beta everywhere we mention it. The same rule applies to everything on the site: live, beta or planned, never implied.

2 In progress

SarpiVault, secrets outside your environment variables

SarpiVault already holds the platform's own secrets, with versioning and an audit trail. The next step is opening it up to your own applications.

Version history per secret. Including who read what and when.
Injection without exposure. Into components and functions without the value ever appearing in an API response, a log or a diff.
Rotation without a full redeploy. Of everything that uses the key.

Why before the rest of recovery: a backup of a system that still keeps secrets as plain environment variables backs those secrets up too. Running the vault for our own secrets first is how we know it holds before we ask you to trust it with yours.

3 Planned

Backup and restore as a product

Restore points you put back yourself from the console, without a ticket and with published retention, already exist for PostgreSQL (shared and dedicated), and dedicated Redis and MariaDB; dedicated PostgreSQL 16 also restores to any moment in the last 7 days through point-in-time recovery. What is left here is the rest: coverage for every resource type, and a scheduled check that it actually works.

Restore points for buckets. The same button as the databases that already have it.
RPO and RTO targets per resource type. In public.
An automated restore test. Running on a schedule, with a result you can see.

That last point is not optional. A backup nobody has ever restored from is an assumption. This deliberately comes before the compute phase: SparxLite and SparxCore will plug into it, rather than each getting their own half-solution.

4 Planned

Managed Domains, your domain without DNS chores

Today you buy a domain somewhere else and then set up the records yourself. That becomes one step inside your Project.

Register and transfer through Sarpius. Buy a new domain, or move an existing one over with a transfer code, paid from the same balance as everything else.
DNS hosted by us. Manage records in the console and through the API, with the same permissions as the rest of your Project.
Wired to your app automatically. Picking a domain for a component is enough: we handle routing and the TLS certificate, without you copying a CNAME anywhere.
No lock-in. You request the transfer code yourself in the console, no ticket needed. Your domain is yours, including when you leave.

Why after backups and before compute: a domain is the first thing an app leans on and the last thing you want to lose. That needs a platform whose own recovery is in order first; every compute form that comes after gets it from day one.

5 Planned New product

SparxLite rebuilt, and SparxCore alongside it

The whole compute line gets sorted in one go. SparxLite moves from fixed sizes to free sizing, and SparxCore joins it: full cloud VMs with their own kernel and root access.

What it is	SparxLite	SparxCore
What it is	Containers	Full cloud VMs
Isolation	Shared kernel	Own kernel and own OS
Access	Managed from the console	Root over SSH, plus an emergency console
Today	Live, on fixed sizes	Not yet available

Free sizing. CPU, RAM and storage set independently at creation and on resize, instead of picking a fixed tier.
A public configurator. You work out a concrete monthly cost for running 24/7 without an account, and that is the same amount you get billed afterwards.
The technical ground rules published. CPU model, shared or dedicated, fair use, TCP and UDP, ports per instance, included bandwidth and what happens above that limit.
DDoS scope for direct game traffic. Stated separately, not only for web traffic behind the router.
SparxCore complete on day one. Create, start, stop, reboot, resize, delete, plus console access when the network is gone. A published image list, IPv4 and IPv6, and firewall rules from the console.
Snapshots and backups from phase 3. The same retention and the same restore button as the rest of the platform, not a second system.
What happens to your data on a host failure. Published per storage type. That is the question VM buyers press on, and rightly so.
SparxLite, SparxCore or a Project. A comparison that says when to pick which, including how it stacks up against traditional game hosting and against an ordinary VPS.

If you are on a fixed SparxLite tier today: we will state what happens to your price when free sizing goes live before it goes live. Not after.

6 Planned

Customer cases with real numbers

Not a testimonial saying it works great, but a production environment you can check.

Required per case: number of components and their role, requests per month, database size and engine, deploy frequency and whether those deploys had downtime.
A real scaling event. From how many to how many replicas, and what set it off.
At least one incident per case. What went wrong and how long recovery took. A case without an outage is not a case, it is an advert.
A real restore case. Plus footage of a deploy, a rollback, autoscaling in action, and an export showing you can leave again.

This sits after phase 3 on purpose. The restore case is the part a technical reader checks hardest, and until then we could not make it honestly.

7 Planned

A second independent zone

First one second, properly designed Dutch zone. Multiple countries only after that. Two locations on the same underlying dependencies are not redundancy, they are a map.

Two separated locations. Physically and operationally, with no shared power, network or storage.
Database failover. Between the two.
Routing that can steer around a location entirely. Including a full location outage, not just a single node.
An explicit zone commitment for SparxCore VMs. Fixed at the SparxCore release rather than engineered around afterwards.
A failover test that has been run, with the result published. Otherwise it is a design, not a zone.

International regions come after that, and then for four concrete reasons: latency outside the Netherlands, a choice in data residency, regional disaster recovery, and customers who will not accept a dependency on a single country.

Ongoing, alongside every phase

The numbered phases are an order: each one has a reason to come after the one before it. These two tracks are not. They run from now on, have no end date, and are not waiting for phase 7.

More frameworks, runtimes and integrations

The work that makes the platform usable for more people: more frameworks the wizard recognises the moment you connect your repository, more runtimes and versions, more database engines, and more ready-made templates.

A public list of supported frameworks, runtimes and versions, each with an honest status: tested, experimental or planned.
The admission rule: something joins that list only once a real repository of it has been detected, built and deployed, and that deployment is running. Not when detection works and the rest is untried.
Set up correctly on arrival: the environment variables and ports a framework needs, without you having to look them up.
Requests via Discord. What you ask for lands on that same public list as planned, so you can follow what happens to it.

Findability and transparency

Small work, cumulative effect.

The full public experience in every language we offer, today English, Dutch, German and French, kept complete as pages are added.
Every feature marked live, beta or planned.
A public architecture and security page.
The DPA and sub-processor list within two clicks from any page.
A summary of an independent security review.
Case studies in the main navigation, next to the changelog and this roadmap.

Where we fall short today

These are not presentation problems. They are here so you know them before you put a production environment on us, rather than afterwards.

Recovery is not complete yet

Restore points you put back yourself exist for PostgreSQL (shared and dedicated), and dedicated Redis and MariaDB, and dedicated PostgreSQL 16 also has point-in-time recovery. Restore points for buckets do not exist yet. For whatever is not covered, keep an export of your own.

Resolved in phase 3

Everything runs in one failure domain

The platform runs in a single location today. An outage that takes that location down takes your application with it. We would rather say so here than have you find out.

Resolved in phase 7

SparxLite only has fixed sizes

Today you pick from a set of predefined sizes. If your workload does not fit one neatly, you pay for a step you do not need. Every size and its monthly price is published on the SparxLite page, so you can at least do the maths.

Resolved in phase 5

Our measurement history is still short

The status page has only been measuring for a short while. There is little to speed up there; what we do instead is be honest about the window and write up every incident in public, including what it taught us.

Grows with time

A year of honest status history with a handful of well-handled outages convinces more than a theoretical 100 percent. This roadmap is the route there, and it gets updated when the order changes rather than supplemented with a second one.

See the status page Request a framework on Discord