Three tiers. One rule: the server never sees source.
One desktop app, one encrypted control plane, one engine on each of your servers. Source code is readable only on your machine — everywhere else it exists as AES-256 ciphertext, or briefly in volatile RAM while it runs. This page is the general picture; every section links to its deep dive.
Your machine — LockFlare Cipher
The desktop app for macOS and Windows. It imports the projects you already have, frontend builds and backends alike, packs them in memory, encrypts them with AES-256-GCM and pushes the ciphertext. Your machine is the only place your code exists as plaintext.
The appThe platform — the encrypted control plane
Holds environments, servers, users, licenses, deployment manifests and the activity log, and holds your builds as ciphertext, stored exactly as received. It orchestrates which version belongs on which server; it is not a party to the contents. The control plane knows your topology and the engine knows your code — briefly, in memory. Neither one holds both.
The three pieces, in the docsYour servers — a single binary
Each server runs lf-engine and nothing else. It registers with its license, fetches the builds assigned to it, decrypts them into volatile RAM, and serves. Power it off and nothing remains. If the box is lost, corrupted or sealed shut, install the engine on a fresh one and push every project back — minutes, not a recovery project.
ServersYour code, in four states
This applies to everything you deploy — a React build, a Node.js backend, a published .NET app, a Go binary. Every project goes through the same four stages, and the only one that produces readable code is the last, in memory, on a machine you own.
Pack
Cipher reads the project folder on your machine — the same folder you develop in — and packs it in memory. Nothing is written to a temp directory. The pack is deterministic: an unchanged project gives an identical archive and an identical version hash. Cipher does not run your bundler or compiler; if the project needs npm run build or dotnet publish, you run it first, as you do today.
Encrypt
The archive is encrypted with AES-256-GCM before it leaves your machine, never on receipt. GCM is authenticated encryption — confidentiality and integrity in one — so a modified ciphertext fails to decrypt rather than executing something you did not write. At no point does an unencrypted copy of your project exist anywhere outside the folder you develop in and the RAM of your own server.
Deliver
The ciphertext is uploaded and recorded against a version. Promoting a build from one environment to another moves that exact artifact — the bytes do not change between UAT and Live, so what you tested is byte-for-byte what ships. Each server holds a license bound to its own address; the engine authenticates with it, and the payload is keyed so a build for one server is not usable on another.
Execute
The engine decrypts the build into volatile memory and runs it there: on Node through the native vm sandbox with one context per domain, on .NET from memory streams into a collectible assembly load context, natively through an anonymous memory descriptor. The filesystem never receives plaintext. No extraction step, no staging directory, nothing left behind when the process stops.
Three guarantees, one architecture
Encrypted at rest
Source is stored as AES-256 encrypted documents. No file names, no structure, no logic — ciphertext, unreadable without the keys that only the licensed engine can use.
Decrypted in RAM
At boot the engine fetches the encrypted payload, decrypts it into volatile memory, loads it and begins serving. The decrypted code exists only as process memory, never as files.
Zero on disk
No .js files, no .dll files, no build artifacts, no dist folder. The server's filesystem holds a single binary launcher and its license, and nothing else of yours.
Inside the engine: a cryptographic launcher
The engine is a compiled, stripped native binary. At boot it verifies its worker, decrypts the runtime image entirely in RAM, and hands the bytes to the host process through an anonymous kernel pipe — no file, no temp directory, no staging area.
- Integrity before keys. The worker shim is SHA-256 verified against a hash compiled into the binary. A single modified byte aborts execution before any decryption begins.
- Anti-debug, continuously. Debugger-attach detection runs at startup and throughout; shared-library injection is detected and blocked; the engine refuses to run with strace, gdb or ltrace on the box.
- Keys never rest. Decryption material lives as obfuscated byte arrays inside the binary, is reassembled in stack buffers, used once, and zeroed.
- Tenants stay isolated. Every domain runs in its own memory sandbox with strict budgets and timeouts, and no access to the host filesystem or to other tenants.
Zero-touch, fleet-wide
No FTP, no SSH, no Docker builds, no CI/CD pipeline. Press push in the app and your encrypted code reaches every engine in the environment — each server decrypts in RAM, loads in memory and starts serving, atomically. No plaintext ever travels over the wire, and no plaintext ever lands on a disk.
What an attacker with root sees
The architecture is honest about where it stops, because a security team will find the edge anyway.
Reads the filesystem
The engine binary and a license. No application source, no assemblies, no dependencies, no configuration.
Snapshots the disk, clones it, walks out with it
The same. Ciphertext at most, and only where a build is stored locally.
Restarts the server
The engine re-fetches and re-decrypts into RAM. Still nothing on disk; the seal, if one is set, is still set.
Attaches a debugger
Nothing — the engine refuses to run with strace, gdb or ltrace present, and shuts down if one appears while it runs.
Reads process memory
The plaintext, if they have root on the running machine and the time to reconstruct it. This is the honest limit of software-only confidential computing: it raises the cost of extraction from "copy a folder" to "attach to a hardened process and rebuild it" — it does not make it impossible.
So the gap is closed another way
Server Enclave removes interactive access to the machine entirely: no SSH, no console, no KVM, no login of any kind, while the engine keeps serving. There is no shell to get root in.
EnclaveThe detail lives here
Node.js runtime
One vm context per tenant, the allowlisted package model, cluster workers, the ten-step boot.
.NET runtime
Published apps loaded from memory streams, one kernel-confined process per application.
Native runtime
Static Go, Rust, Zig, C and C++ binaries launched from an anonymous memory descriptor.
Security model
The five gates on every request, identity and sessions, transport, the threat model.
Root into a server. Find nothing.
The proof is the empty filesystem, and it is the audit we invite every security team to run on their own test box. Write to us with what you deploy, where, and to whom.