Any compiled binary. Zero files.
Build your backend in Go, Rust, Zig, C or C++, compile it to a single self-contained executable, and push the binary. Cipher decrypts it in volatile memory and launches it straight from an anonymous memory descriptor — no language runtime on the server, no interpreter, and nothing of yours ever written to disk. Not your binary, not the launcher that runs it.
Build a static binary. Push it.
No SDK, no base classes, no LockFlare code in your program. You compile the way you always do; Cipher encrypts the executable, stores it as ciphertext, and runs it from RAM on your server. The one requirement is that the binary be statically linked — self-contained, with no dependency on shared libraries present on the host, because there is no host filesystem for it to find them in.
Your side: a normal build
Produce a static Linux x86-64 executable and push it. Go with CGO_ENABLED=0; Rust against the musl target; Zig statically linked by default; C and C++ with -static. Any toolchain that emits a self-contained ELF works.
Our side: launched from memory
On the server your binary is decrypted in RAM and written into an anonymous, sealed in-memory file created with memfd_create. The engine calls fexecve on that descriptor, executing your program directly from memory. Ciphertext to running process, without ever becoming a file — no path to cat, copy, or attach to.
Backend only, by nature
A compiled binary is a program to run, not a folder of files to serve. Your binary owns its own HTTP server, its own concurrency and its own routing; Cipher runs it and routes your domains to it. If you need to serve a built frontend, your program serves it, exactly as it would anywhere else.
If it compiles to a static ELF, it runs
The native runtime is not tied to one language. It runs the output, not the source.
Go
CGO_ENABLED=0 go build — a static ELF out of the box.
Rust
Build against the musl target for a self-contained binary.
Zig
Statically linked by default; cross-compiles cleanly.
C and C++
Link with -static — musl or glibc — for a standalone executable.
Anything else
Any toolchain that emits a static Linux x86-64 ELF is a first-class citizen.
Not supported
Dynamically linked binaries that expect shared libraries on the host. There is no host filesystem for them to find.
From ciphertext to running process
Every step happens in memory. The decrypted binary exists only as an anonymous memory descriptor for the instant it takes to launch, and is scrubbed immediately after.
Environment check
The engine refuses to start if strace, gdb or ltrace is present, and guards the process against debugger attach and library injection 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.
Fetch the encrypted binary
Your compiled binary and the native supervisor arrive from the control plane as ciphertext under a per-request symmetric key.
Decrypt in memory
The keys embedded in the delivered payload are extracted and the binary is AES-256 decrypted entirely in RAM. The plaintext ELF exists only as bytes in memory.
Sealed memfd
The decrypted ELF is written into an anonymous in-memory file and sealed — a descriptor with no name and no path anywhere on the filesystem.
fexecve
The engine executes the binary directly from the memory descriptor. Your program starts without a single byte of it touching disk.
RAM scrub
The engine zeroes its in-memory copy of the decrypted binary and scrubs the decryption keys.
Confinement and serving
The process runs inside private network, mount and PID namespaces as a dedicated unprivileged user with enforced caps. It binds its port, and the Cipher proxy routes your domains to it.
The smallest footprint of the three
There is no language runtime, no dependency tree, no build artifacts — nothing on disk but the launcher and its license. Your compiled binary is never in that list. In RAM: the decrypted ELF in its sealed memfd, the running process image, the environment's variables, the per-request keys, and the decryption keys until the launch is done.
Native apps get the same per-application confinement as every other runtime. A compiled binary is opaque to Cipher, so it runs walled off from the host and from every other app: its own network, mount and PID namespaces; a dedicated non-root user with no ambient capabilities; enforced memory and process limits; and no route out of its namespace by default — a compromised binary has nowhere to send data.
One engine, three runtimes
The native runtime ships in the same engine as Node and .NET — one binary on the server, the runtime chosen per environment. Bring a static build and a test box.