Built the way large clouds are built. Ready for your scale.
The engineering behind Nexovia follows the patterns that keep the world's biggest platforms running: no single copy of anything important, automatic failover, backups that are restored and checked, and every change tested before it reaches you. What we are building now is the customer base and the scale.
Four rules every layer follows
No single copy
Data and the services that guard it run on several servers, so losing one is a non-event.
Fail over by itself
When a server stops, traffic moves without anyone pressing a button.
Restore, don't hope
Backups are restored and compared automatically, not just written.
Check every change
Code is scanned and health-checked before it serves a single request.
What runs where, and what happens when a server fails
Every layer below is live today on servers in India, on a private network with no public addresses.
| Layer | How it is built | If one server fails |
|---|---|---|
| Databases | Managed PostgreSQL on a three-server cluster with one synchronous standby. Every change is archived continuously off the servers, and a full copy is taken every night. | A standby takes over in seconds, with no committed data lost |
| Nexovia Vault | Secrets on a three-server cluster with encrypted storage. Every app has its own identity and reads only its own secrets. | The other two servers keep serving |
| Nexovia ID | Sign-in on a two-server cluster that shares sessions; both servers take traffic. | The remaining server carries all sign-ins; people stay signed in |
| Nexovia Shield | The public entrance on two servers kept identical every five minutes, behind network protection that absorbs attacks. | The second server holds the same sites and certificates |
| Internal naming | The service that tells servers where everything lives runs on three members, read by two name servers that also cache answers for an hour. | Names keep resolving |
| Cache | A Redis-compatible cache on three servers with automatic leader election. | A replica becomes leader on its own |
| Builds | A separate, fenced build service builds every release without root rights and scans it before it can reach production. | Live apps keep running; releases wait |
| Nexovia Sandbox | Every customer app runs in its own sandbox with CPU, memory and process limits and a network fence. A new version starts beside the old one and must pass its health check first. | Apps on two servers each: in progress (see the plan below) |
| Nexovia Monitor and Alerts | Every server, database and public address is measured around the clock; problems reach the on-call engineer within a minute. | Health checks from a second location: next step |
Backups that are proven every day
What is kept
Every database, the vault, sign-in data, code repositories, app files and the platform's own control data, encrypted before they leave the server and copied off-site in India. Daily copies for a week, weekly for a month, monthly for six months.
How it is proven
Every night the newest database copy is restored into an empty server and compared database by database with the live data. Every week the off-site copy is restored and checked. The database can also be brought back to any moment, not just last night.
Who can unlock it
The backup keys are held in the vault and, separately, by two named directors of the company, so no single person can lose or misuse them.
Changes made safely
Before any change to a core system, every backup is run and the off-site copy verified. Changes happen through scripted, audited procedures, one server at a time.
Recent evidence
| Date | What we tested | Result |
|---|---|---|
| 30 October 2026 | Stopped one sign-in server during live use | Sign-in kept working; the server rejoined the cluster by itself |
| 30 October 2026 | Internal naming moved from one member to three while serving | No failed lookups; all three members hold identical data |
| Every night | Full restore of the newest database copy and comparison with live data | Passing |
| Every week | Restore of the off-site backup copy | Passing |
| 22 October 2026 | Ten kinds of project uploaded and released through the customer path | Ten of ten live, 16 seconds to under 3 minutes each |
| 17 October 2026 | Planned switch of the database leader during a maintenance window | Completed with point-in-time recovery switched on and no archive failures |
The plan, with dates
We publish what is in progress so you can hold us to it.
| Step | What it adds | When |
|---|---|---|
| Load-balanced public entrance | Both entrance servers take traffic; either can fail | November 2026 |
| Apps on two servers | Every app without local files runs twice; a server loss goes unnoticed | November 2026 |
| Second data centre | Standby database and recovery tools in another location, with a recovery drill twice a year | November to December 2026 |
| Written uptime commitment | A service level with credits, once measured history supports it | Early 2027 |
| ISO/IEC 27001 and ISO 9001 | Independent certification of security and quality management | Planned for 2027 |
The engineering is in place. Bring your apps.
Our first ten outside customers get their move done by our engineers, launch pricing and a named engineer. Your apps run on everything on this page from day one.
Reliability questions
What happens to my app if a Nexovia server fails?
Databases, secrets, sign-in, internal naming and the cache fail over to another server automatically. Apps themselves run on one server today and on two from November 2026; until then a failed app server is replaced from the same checked image.
How much data can be lost in a failure?
For databases, close to none: changes are archived continuously and a synchronous standby holds every committed change. Files that an app keeps on its own server are backed up every night.
Is Nexovia ready for production apps?
Yes. Our own group's businesses run their live sites and apps on it today, on the same platform and plans customers use.
Do you have an uptime SLA?
Not yet in writing. We will publish one with service credits once enough measured history supports it, planned for early 2027.