Why the name. Sakina (Arabic سكينة, sa-KEE-na) means calm, tranquility. That is what we wanted a server to be for the people responsible for it: quiet and steady, with no alarms at night and no manual rollbacks.
Sovereignty starts at the bottom
If you do not control the layer under your software, you do not fully control your data. SakinaOS is written from scratch in Rust, without a line of C and without third-party code in the image — there is nothing foreign to audit or to trust.
- No remote shell and no SSH: there is no remote login to abuse
- Updates are signed and verified on the machine itself
- Disk keys never touch the disk
- The same image runs on hardware you own and in a public cloud
Built for one job
A general-purpose system is built to run anything. SakinaOS runs one application per machine. There are no processes, no system calls and no general-purpose scheduler between the application and the hardware — fewer layers, less waiting.
The application is built together with the system into one signed file. A node with its operating system takes about 5 MB.
Updates you do not have to fear
Every image carries a signed manifest checked at boot. Updates use two slots: the new version boots on probation, and if it is not confirmed, hangs or crashes, the machine returns to the previous version by itself. Building twice from the same sources gives a byte-identical image, so anyone can check that what runs is what was signed.
Managed over a locked channel
A node is managed only over our ATL protocol inside TLS 1.3, where both sides check each other's keys. Key exchange is post-quantum by default: hybrid X25519 + ML-KEM-768. Certificates carry roles — a monitoring role can watch but change nothing; an unlock role can only unlock disks.
Disks that keep their word
Disks are encrypted. The key arrives over the management channel at boot and lives only in memory. Data is verified in the background, disk health is watched, and suspect areas are quarantined automatically until an operator clears them. Drivers for NVMe, SATA, Intel 10 GbE and standard virtual devices are our own, written from official specifications, on ARM64 and x86-64.
Measured
- Power was cut 5 times during writes on a dedicated AMD EPYC server with NVMe (October 2026): all 248 acknowledged writes were intact, none lost, none corrupted
- A 6-hour run in an x86-64 virtual machine with 4 vCPU (October 2026): 17 update cycles — 8 confirmed, 9 rolled back automatically — 35 reboots and about 407,000 HTTP operations, with every confirmed piece of data intact and memory use flat
- A node with its own operating system: about 5 MB
The 9 rollbacks were deliberate: those updates were left unconfirmed to prove that rollback happens on its own.