LockFlare

How it works

Four stages: pack, encrypt, deliver, execute. The only one that produces readable code is the last, and it happens in memory on a machine you own.

1 · Pack

LockFlare 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, so an unchanged project produces an identical archive and an identical version hash.

What gets packed is your build output as it stands. LockFlare does not run your bundler, compiler or package manager. If your project needs npm run build or dotnet publish, you run it first, exactly as you do today.

2 · Encrypt

The archive is encrypted with AES-256-GCM before it leaves your machine. GCM is authenticated encryption: it protects confidentiality and integrity together, so a modified ciphertext fails to decrypt rather than executing something you did not write.

Encryption happens on your machine, not on receipt. 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.

3 · Deliver

The ciphertext is uploaded to the Cipher Encrypted CDN and recorded against a version. Promoting a build from one environment to another moves that exact artifact — the bytes do not change between Development and Live, so what you tested is byte-for-byte what ships.

Each of your servers holds a licence bound to its own IP address. When the Engine fetches a build it authenticates with that licence, and the payload is keyed so that a build for one server is not usable on another.

4 · Execute

The Engine decrypts the build into volatile memory and executes it there. On the Node runtime that means loading modules through Node’s native vm sandbox with per-domain isolation; on .NET it means Roslyn in-memory compilation into a collectible AssemblyLoadContext.

Either way, the filesystem never receives plaintext. There is no extraction step, no staging directory, and nothing left behind when the process stops.

What an attacker with root sees

They do thisThey get
Read the filesystemThe Engine binary. No application source.
Snapshot the diskThe same. Ciphertext at most, and only if the build is stored locally.
Restart the serverThe Engine re-fetches and re-decrypts into RAM. Still nothing on disk.
Attach a debuggerNothing — the Engine refuses to run with strace, gdb or ltrace present.
Read process memoryThe plaintext, if they have root and the process is running. This is the honest limit.
That last row matters, so we state it plainly rather than burying it. A sufficiently determined party with root on a running 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 and reconstruct it” — it does not make it impossible. Server Enclave exists to close the remaining gap by removing interactive access to the machine entirely.