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 کے اور شाئع شدہ 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