Security is the architecture.
When source code never exists on the filesystem, whole categories of file-based attack have nothing to operate on — not mitigated, absent. This page is every security layer of Cipher in one place, including the one place the architecture stops and says so. The structural detail lives in Architecture; the per-runtime threat models on the Node.js, .NET and native pages.
Every request. Five gates.
Every HTTP request passes five independent checks before tenant code runs. Total overhead: under one millisecond.
TLS 1.3 termination
In front of the server or on it — either way, nothing readable on the wire.
WAF inspection
The embedded firewall reads bodies, query strings, headers and paths. SQL injection, XSS, command injection, path traversal and prototype pollution are classified and blocked before they reach your code; every block is logged with its classification, and a per-IP leaky bucket turns five violations into a five-minute block.
Token and IP binding
A session token is bound to the address it was issued to. Stolen, it fails from anywhere else.
Permissions, three tiers
Global platform operations, per-project capabilities, per-environment rights — evaluated on every request.
Sandbox isolation
The request lands in the tenant's own sandbox: a vm context on Node, a kernel-confined process on .NET and native. Nothing else is reachable from there.
Two-factor for everyone. Sessions that cannot be stolen.
A second factor is mandatory for every user at every privilege level — WebAuthn hardware keys, authenticator apps, or an emailed PIN. Administrative and Enclave operations require a fresh challenge: a stolen session token cannot toggle server state. Sealing a server takes a code the server can verify, so Touch ID is not offered for it — a check that happened locally on your laptop is not the same thing.
- Per-user login rules beyond the password: working-hours windows with a timezone, allowed days of the week, IP allow-listing by address or CIDR range, automatic session timeout.
- Failed attempts trigger progressive per-IP lockout, and login responses never reveal whether a username exists.
- Tokens rotate on every new login; single-session enforcement is a switch. A USB drive can serve as a WebAuthn security key.
- Invitation-only onboarding: no self-registration, no user enumeration.
Nothing readable ever travels
Everything moves over TLS 1.3 — and on top of it, every leg of the pipeline carries its own encryption and its own authentication. Plaintext exists on your machine, and nowhere in between.
Leg 1 — from your machine
Cipher zips your bundle in memory and encrypts it with AES-256-GCM before anything touches the network. Encryption happens on your machine, never on receipt.
Leg 2 — to your fleet
Each engine receives the encrypted bundle with per-request key material and verifies its SHA-256 integrity on arrival. Replaying an old delivery response yields nothing.
Leg 3 — control plane ⇄ engine
Every control operation is signed both ways with HMAC-SHA256 and compared in constant time. Nonces expire in 30 seconds; a captured command can never be replayed.
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 periodically re-fetches the encrypted bundle and compares it to what is in memory. In-memory code that differs from the master is overwritten at once — tampered code survives no longer than one check interval.
Anti-debug enforcement
strace, ltrace, gdb and perf are scanned for every five seconds. Found, the engine shuts down instantly, terminates the application processes and clears memory. They must be uninstalled before it will start.
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. The worker shim is SHA-256 verified before every start.
Memory-dump hardening
On Node, code runs as compiled bytecode derived from heavily obfuscated source — a dump yields neither. On .NET, assemblies load into collectible contexts inside kernel-isolated processes. Natively, the ELF lives in a sealed descriptor with no path. A sealed server removes the vector.
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 resource caps per app.
No supply chain on disk
No node_modules directory exists on the server. Dependencies are installed once on the host and bridged through a controlled proxy — application code never resolves packages from the filesystem.
Attacks that become structurally impossible
These are not mitigations with residual risk to manage. When the attack surface does not exist, the attack does not either.
Ransomware
No application files on disk to encrypt. There is nothing to hold hostage.
Source code exfiltration
No files to copy. Root SSH reveals no application code; on a sealed server there is no SSH.
Local file inclusion
Directory traversal has no targets. There are no application files to include — the paths do not exist.
Insider file access
Root-level administrators cannot reach source through the filesystem. Code exists only as compiled artifacts in isolated memory.
Physical access
Disk cloning or drive removal yields encrypted artifacts at most. On a sealed server, even the physical console rejects login.
Session and credential attacks
Tokens are IP-bound. Credential stuffing hits progressive per-IP lockout with zero user enumeration.
The honest limit, and what closes it
A sufficiently determined party with root on a running, unsealed machine can inspect that machine's memory. Software-only confidential computing raises the cost of extraction from "copy a folder" to "attach to a hardened process that shuts down on sight and reconstruct it from a dump" — it does not make it impossible, and we would rather say so here than have your security team find the sentence missing.
Server Enclave closes the gap by removing interactive access entirely: SSH, console, KVM, IPMI and the hosting panel are disabled at the operating-system level while your applications keep serving. There is no shell to get root in, so there is no session from which to dump memory. Sealing survives reboot; unsealing takes a second factor, from the app.
Server EnclaveConfidential computing without the hardware
Hardware confidential computing needs specialised CPUs with trusted execution environments, specific cloud instance types and attestation workflows. Cipher reaches the same outcome in pure software — on any Linux server, in any datacenter, with any provider, bare metal included.
Hardware TEEs
A special chip, and its rules: a vendor's silicon, a provider's instance family, an attestation service in the loop, and a port of your application to the enclave's model.
LockFlare Cipher
Any Linux server, your rules: the application you already have, unmodified, encrypted at rest and run only in memory, with the box itself sealed when it should not be touchable. A $50-a-month dedicated server becomes an enclave.
Audit it on your own box
Take root on a test server running Cipher and look for the application. Then try to attach a debugger. Write to us and we will set the server up with your team watching.