Straight answers, including the ones that are not flattering. Missing something? Ask in Discord and it lands here.
Sarpius takes your code and runs it in production, so you do not manage servers, networking or deploys yourself. You connect a repository, the platform detects what is in it, provisions what it needs and deploys it.
The unit you work in is a Project: one application made of multiple components, a front-end, a back-end, workers, plus the databases, storage and routing they share. Built for developers and small teams who want clarity rather than knobs.
Same idea, different home. Sarpius runs entirely on our own hardware in the Netherlands, so your data stays under European jurisdiction and you are not depending on a US cloud provider.
Billing is per minute from a wallet, so you pay for what actually runs instead of a monthly slab. And we publish what we cannot do yet, which is the other half of the difference.
No waitlist and no invite. Sign up with an email address, connect a repository and deploy your first app for free.
Every app gets an automatically generated subdomain on sarpius.app with a certificate, so you have a working URL before you own a domain.
Your first app is free and stays free: one small container, 10 GB of bandwidth, a free subdomain with TLS, no credit card and no trial clock.
Beyond that, everything is metered per minute from your wallet:
These are the rates the biller charges and they exclude VAT; the calculators on the pricing page add it. Because it is metered per minute, an app you stop billing stops costing, without a cancellation.
If it runs in a container, it runs on Sarpius. On top of that the connect-a-repository wizard recognises 45 frameworks and runtimes and configures the build, the port and the environment variables for you.
Among them: Next.js, Nuxt, SvelteKit, Astro, Angular, React, Vue, Vite and Remix-style React Router; Laravel, Symfony, WordPress and plain PHP; Express, Fastify, NestJS, Hono and Node.js; Django, Flask, FastAPI, Streamlit and Gradio; Go, Java on Maven or Gradle, .NET; Hugo, Eleventy, Docusaurus, MkDocs and static sites; plus Strapi, PocketBase and Discord bots.
Missing your stack? Ask in Discord. It goes on the public list as planned, and it only moves to supported once a real repository has been detected, built and deployed.
Three engines, reachable over TLS with any standard client, provisioned and linked to your app from inside the Project.
More engines arrive through the same ongoing track as frameworks: something is listed once a real database of it has been provisioned, linked and used, not when the code path exists.
On our own infrastructure in the Netherlands. Your data stays within the EU, under the GDPR, and never touches a non-EU cloud provider. That is the reason the platform exists, not a checkbox on it.
The honest addition: everything runs in a single location today. An outage that takes that location down takes your application with it. A second, genuinely independent zone is on the roadmap, and we will publish the failover test when it exists.
For shared and dedicated PostgreSQL, and for dedicated Redis and MariaDB, yes, and you do it yourself: make a restore point, or turn on a nightly one, and put your database back from the console without a ticket. Every restore first saves the current state as a safety point, so a restore can itself be undone. Dedicated PostgreSQL 16 can also turn on point-in-time recovery, restoring to any second in the last 7 days instead of only to the latest restore point.
What does not exist yet: self-service restore points for buckets, and a second independent location or zone. Separately, Sarpius makes a nightly, client-side encrypted off-site copy of all object-storage buckets, the platform databases and platform configuration, for disaster recovery of the platform; it is not a per-customer restore service. For anything not covered, keep your own export or dump.
Yes, and that is deliberate. Your code lives in your own git repository; we never become the only copy of it.
Databases are ordinary PostgreSQL, Redis and MariaDB reachable with standard clients, so a standard dump is a standard dump. Owning your whole application is only acceptable if you can walk out with it.
Ask in Discord, which is the fastest line to us, or open a support ticket and we will pick it up.
For anything that looks like an outage, the status page carries live uptime per component and the history of every incident we have handled, including what went wrong.
In order: the numbers and recovery limits published up front, then Serverless Functions, then SarpiVault for secrets, then backup and restore as a real product, then a rebuilt SparxLite with free sizing alongside SparxCore cloud VMs, then customer cases, then a second independent zone.
The roadmap page carries the reasoning for that order and names what we fall short on today.
A question that is not answered here is a question this page is missing. Ask it in Discord and it gets added.