Roadmap Updated 10 October 2026

What Sarpius is building, and in what order

Sarpius में अब features की कमी लगभग नहीं है। कमी प्रमाण की है: ऐसा recovery जिसे वादे के बजाय सचमुच टेस्ट करके दिखाया गया हो, और production के ऐसे आँकड़े जिन्हें आप खुद जाँच सकें। Database recovery मौजूद है; आगे हम पहले वह खोलेंगे जो हम अपने लिए पहले से चलाते हैं, फिर बाकी recovery, और फिर compute line। यह पेज उन जगहों के नाम भी बताता है जहाँ हम आज कमज़ोर पड़ते हैं।

In progress Up next Planned

Where we are today

Deploys, automatic TLS के साथ routing, managed databases (हर dedicated database पर TLS के साथ), public buckets वाला object storage, message queues, edge cache, scheduled jobs और per-minute billing सब production में चलते हैं, साथ ही हर component की uptime और incident history वाला public status page भी। Sarpius Functions closed beta में चल रहा है: Node.js, Python और PHP, हर request पर या schedule पर, GiB-second और invocation के हिसाब से billing। किसी application का पूरा lifecycle console, public API और AI agents के लिए MCP server से चलाया जा सकता है, और जब आप छोड़ना चाहें तो Project को migration bundle के रूप में export किया जा सकता है। SparxLite आज चलता है, अभी fixed sizes पर, और हर size और उसकी कीमत प्रकाशित है। जो restore points आप खुद वापस लाते हैं वे PostgreSQL (shared और dedicated), और dedicated Redis और MariaDB के लिए चलते हैं; dedicated PostgreSQL 16 पर point-in-time recovery भी है।

उस सूची में क्या नहीं है: Functions के लिए environment variables और database connections, आपकी अपनी applications के लिए secrets management, buckets के लिए restore points, और एक दूसरा स्वतंत्र location। ये नीचे phase 1, 2, 3 और 7 हैं, और जब तक ये मौजूद नहीं होते, हम हर resource type के लिए बताते हैं कि वास्तव में क्या वापस लाया जाता है और क्या नहीं।

0 In progress इस महीने

बाकी आँकड़े सबसे आगे

हर component की uptime, उसकी measurement window और हर SparxLite size की कीमत पहले से बिना क्लिक के साइट पर है। तीन आँकड़े अभी भी गायब हैं, या किसी लिंक के पीछे हैं।

  • Status page पर recovery time और deploy success। हर component का mean time to recovery और सफल रहे deploys का हिस्सा, उस uptime के बगल में जो पहले से वहाँ है।
  • SLA वहाँ जहाँ सवाल उठता है। Pricing, databases और autoscaling पर availability target और response times का छोटा सारांश, पूरे दस्तावेज़ के लिंक के साथ। यह एक target है, गारंटी नहीं, और यह हम साफ़ कहते हैं।
  • हर resource type के लिए recovery limits। Databases के लिए आज प्रकाशित हैं। Buckets, apps और SparxLite आगे आते हैं: क्या वापस लाया जाता है, अधिकतम कितना data खो सकता है, और कार्रवाई कौन शुरू करता है, वहाँ भी जहाँ जवाब प्रतिकूल है।

जिस कसौटी पर हम खुद को कसते हैं: आप हमें ईमेल किए बिना अपना जोखिम और अपना बिल आँक सकें। "हमें नहीं पता" अब कहीं भी तथ्यात्मक जवाब नहीं रहता।

1 In progress

Sarpius Functions, closed beta से बाहर

Functions पहले से आपके Project के अंदर, Firecracker microVMs में, अपनी routing, members और billing के साथ चलते हैं। उन्हें closed beta में रोके रखने वाली बात यह है कि वे अभी आपकी बाकी application तक नहीं पहुँच सकते।

  • हर environment के लिए environment variables। उसी तरह सेट होते हैं जैसे किसी भी दूसरे component के लिए।
  • Database connections। किसी database को function से ठीक वैसे जोड़ें जैसे आज app से जोड़ते हैं।
  • सबके लिए खुला। Beta access की ज़रूरत नहीं, वही GiB-second और invocation की कीमतें और वही spending caps।

तब तक Functions को हम जहाँ भी बताते हैं वहाँ closed beta चिह्नित है। यही नियम साइट की हर चीज़ पर लागू है: live, beta या planned, कभी अनकहा नहीं।

2 In progress

SarpiVault, आपके environment variables से बाहर secrets

SarpiVault पहले से platform के अपने secrets रखता है, versioning और audit trail के साथ। अगला कदम इसे आपकी अपनी applications के लिए खोलना है।

  • हर secret का version history। इसमें यह भी कि किसने क्या कब पढ़ा।
  • बिना उजागर हुए injection। Components और functions में, इस तरह कि value कभी API response, log या diff में न दिखे।
  • पूरे redeploy के बिना rotation। हर उस चीज़ का जो इस key का उपयोग करती है।

बाकी recovery से पहले क्यों: जो system अभी भी secrets को सादे environment variables के रूप में रखता है, उसका backup उन secrets का भी backup ले लेता है। पहले अपने secrets के लिए vault चलाना ही वह तरीका है जिससे हम जानते हैं कि वह टिकता है, इससे पहले कि हम आपसे अपने secrets उसे सौंपने को कहें।

3 Planned

Backup and restore as a product

जो restore points आप खुद console से वापस लाते हैं, बिना ticket के और publish की गई retention के साथ, वे PostgreSQL (shared और dedicated), और dedicated Redis और MariaDB के लिए पहले से मौजूद हैं; dedicated PostgreSQL 16 भी point-in-time recovery के ज़रिए पिछले 7 दिनों में किसी भी पल पर वापस जाता है। यहां जो बाकी है वह है: हर resource type के लिए कवरेज, और एक नियमित जांच कि यह सच में काम करता है।

  • 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 isSparxLiteSparxCore
What it isContainersFull cloud VMs
IsolationShared kernelOwn kernel and own OS
AccessManaged from the consoleRoot over SSH, plus an emergency console
TodayLive, on fixed sizesNot 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.

  • हमारी दी जाने वाली हर भाषा में पूरा public अनुभव, आज English, Dutch, German और French, पेज जुड़ने के साथ पूरा रखा गया।
  • 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 मुख्य navigation में, changelog और इस 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 अभी पूरी नहीं है

जो restore points आप खुद वापस लाते हैं वे PostgreSQL (shared और dedicated), और dedicated Redis और MariaDB के लिए मौजूद हैं, और dedicated PostgreSQL 16 पर point-in-time recovery भी है। Buckets के लिए restore points अभी मौजूद नहीं हैं। जो कवर नहीं है, उसके लिए अपना खुद का export रखें।

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

आज आप पहले से तय sizes के एक सेट में से चुनते हैं। अगर आपका workload किसी में ठीक नहीं बैठता, तो आप ऐसे step के लिए भुगतान करते हैं जिसकी आपको ज़रूरत नहीं। हर size और उसकी मासिक कीमत SparxLite पेज पर प्रकाशित है, ताकि आप कम से कम हिसाब लगा सकें।

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