One binary on the server. Nothing else.
A Cipher server is an appliance, not a computer you keep. It runs the engine and nothing else — no database beside it, no second application, no files that matter. That constraint is what makes it disposable: lose the box and you install the engine on a fresh one, and the environment pushes everything back. Minutes, not a recovery project.
On disk, and in RAM
The central claim of the architecture, as a list: what exists on the server's disk, and what exists only in process memory.
On disk — persistent
No application source. No node_modules. No assemblies, no NuGet packages, no compiled bundles, no build artifacts, no configuration, no .env. Nothing LockFlare-related on the persistent filesystem but the launcher and its license.
In RAM — volatile
Loaded fresh on every engine start, scrubbed on process exit. Power off the server and every LockFlare artifact disappears within milliseconds.
A two-minute terminal session, once
Add the server in Cipher — a label, its public IP, the cores it may use. That issues a license bound to the address; copy it. Download the engine build Cipher hands you for the runtime you chose, run it on the box, paste the key. From that point on the machine is a runtime: the app pushes everything else, and you never type into that server again unless you want to.
- Linux x86-64 with systemd, as root. Ubuntu, Debian, Rocky, Alma — any mainstream distribution. Node.js 24 for the Node engine, the ASP.NET Core 10 runtime for .NET; nothing at all for native.
- Port 80 open, always: the control plane reaches the server by IP over HTTP for reloads, health checks and Enclave, and cannot use a certificate issued for your domain. Port 443 only if the server terminates TLS itself.
- No strace, gdb or ltrace on the box. The engine refuses to coexist with them.
From exec to serving
Every engine boots the same way; the runtimes differ only in what the handoff carries. The detail per runtime is on its own page.
Environment check
The engine refuses to start if debugging or tracing tools are present. Debugger-attach detection and shared-library injection protection guard the process from the first instruction.
License validation
The engine reads its license and presents it to the control plane, which checks it against the account and the source address. Licenses are IP-bound; an invalid or expired one halts the boot.
Runtime fetch and integrity
The encrypted runtime image arrives under a per-request key; its worker shim is SHA-256 verified against a hash compiled into the binary. A single modified byte aborts before any key is used.
In-memory handoff
The engine spawns the host process and streams the decrypted image over an anonymous pipe — no file is written. Then it zeroes its own copy, scrubs the keys and enters a heartbeat loop.
Your build
The live runtime authenticates with its license, fetches the builds assigned to this server, decrypts them into RAM, compiles or loads each into its own sandbox, and begins serving on your domains.
The engine defends itself
Protection does not stop at encryption. The running engine keeps verifying its own integrity, watches for tampering, and refuses to operate under inspection.
Self-healing code
A health-check process periodically re-fetches the encrypted bundle and compares it to what is in memory. If the in-memory code differs from the master it is overwritten at once — tampered code survives no longer than one check interval.
Anti-debug enforcement
The engine scans for strace, ltrace, gdb and perf every five seconds. If any appears, it shuts down instantly, terminates the application processes and clears memory. They must be uninstalled before the engine will start again.
Mutual authentication
Control plane and engine authenticate each other with HMAC-SHA256 and constant-time comparison. Privileged operations carry a single-use nonce with a 30-second life; a captured command can never be replayed.
Keys never rest
Decryption material lives as obfuscated byte arrays inside the binary, is reassembled in stack buffers, used once, and zeroed. The engine's own environment, including the license, is never passed through to your application.
Memory-dump hardening
On Node, code executes as compiled bytecode derived from heavily obfuscated source; on .NET, assemblies load into collectible contexts inside kernel-isolated processes; natively, the ELF lives in a sealed memory descriptor with no path. A sealed server removes the vector entirely.
Isolation by default
Node: one context per application with its own memory limit, one worker per licensed core, crash containment with a two-second respawn. .NET and native: private network, mount and PID namespaces, a dedicated unprivileged user, enforced memory and process caps per app.
Server goes down? Back in minutes.
Hardware fails, drives corrupt, providers have outages. With Cipher none of it matters, because nothing irreplaceable lives on the machine: your source, your configuration and your deployment state live in the platform, encrypted and versioned, and on your own storage if you choose.
Recovery is not a restore — it is a fresh install. Provision a new server, install the engine, and the environment pushes your entire stack back. Same code, same APIs, same sites. No backups to locate, no snapshots to restore. The server is a runtime; the platform is the source of truth.
The constraint cuts the other way too: put a database on a Cipher server and you have made something you must back up, restore and care about — and the whole recovery story goes with it. Keep the box dedicated.
Bring a test box
Any Linux server at any provider. We will install the engine with you, push a project, and let your security team take root and look for it.