Turn the server into a sealed enclave.
Server Enclave disables every login method on the machine — SSH, console, remote access, all of it. The server keeps serving your applications, but no one can get in. Not the hosting provider, not the client's IT department, not root with physical access. Sealing is controlled entirely from the app; no command line is needed, and none would help.
Every door closes. The code keeps running.
The server transitions from a general-purpose machine into a locked appliance. All interactive access is disabled — but sites, APIs, reloads and pushes continue without interruption.
SSH — disabled
Remote shell access is terminated immediately. Active sessions are disconnected, new connections rejected. The server cannot be reached over SSH by anyone, root included.
Console — disabled
Physical and virtual console access is blocked. Walking up to the machine and typing credentials will not work — KVM, IPMI and hosting-panel consoles are locked out too.
Runtime — still running
Your applications, APIs and sites keep serving. Pushes and reloads still land. Health is still reported. Only human access to the operating system is gone.
One action. Cryptographically authorized.
Every seal and unseal is authorized by a second factor and an HMAC-signed, single-use nonce. A stolen session token cannot seal or unseal a server. The state change is shown before you commit — unsealed on the left, sealed on the right — and the app asks for two deliberate things on the way: the acknowledgement that the engine runs under a managed service, and the server's name, typed.
- Identity verification, every time. An authenticator code or an emailed PIN — not Touch ID, on purpose. Sealing needs a code the server can verify, not a check that happened locally on your laptop.
- Survives reboot. Restarting the server does not restore access. The engine detects the sealed state on boot and keeps it: the server comes back online, serves, and stays locked. The only way in is through the app.
- Nothing irreplaceable on the machine. No source lives on the server; it is pulled encrypted on every boot. The seal protects the machine; the platform protects the code.
Before you seal
Read this before sealing anything. It is the right end state for a production appliance, and a bad surprise if you did not mean it.
A managed service, as root
The engine must run under systemd or PM2, as root. This is the one that matters: sealing without one locks the server permanently, because there is no login to restart the engine by hand. The app asks you to confirm it explicitly.
No debug tools on the box
strace, gdb and ltrace must not be installed. Those tools attach to a running process and read its memory — precisely the attack a seal exists to make impossible — so the engine refuses to seal a machine that has them.
Online, on port 80
The control plane reaches the server by IP over HTTP for health, reloads and Enclave, and the unseal comes the same way. A sealed server whose engine stops answering for good cannot be recovered — not by SSH, not by console, not by the provider, not by us. Rebuild it, in minutes, because nothing irreplaceable is on it.
Before and after
On-premises deployment has always meant surrendering control. The moment your software lands on the client's machine, their administrators hold every key. Enclave changes the equation — both sides win.
Any traditional on-prem deployment — their server, their rules
- Read your source code
- Copy it anywhere
- Modify your runtime
- Extract your secrets
- Tamper with configuration
- Bypass your licensing
With Enclave — their hardware, your seal
Still theirs: reboot and rack the machine, monitor hardware health.
Sealed away: logging in to the server, reading or copying code, tampering with the runtime, bypassing licensing.
Your app runs on their infrastructure. Their data stays local. Your IP stays protected.
When the server should not be touched
Client infrastructure
Deploy your application on a client's server and seal it. They run your product and their sysadmins maintain the hardware — but nobody reads, copies or tampers with your code or configuration.
Outsourced IT
Your hosting is managed by a third-party team. Enclave lets them monitor hardware health and reboot the machine, and never access the application layer or extract data.
Production lockdown
Lock production after deployment. No one — not even your own team — can SSH in and make an untracked change. Every modification goes through the app and the encrypted pipeline, and lands in the activity log.
Regulated on-premises
Healthcare organisations and banks run your application on their infrastructure without exposing your source to their IT department; data sovereignty on their side, zero IP leakage on yours.
Defense and air-gapped
On-premises, zero-trust infrastructure with no readable source on the server, and no interactive path onto it at all.
The untrusted runtime
The server itself is untrusted; the platform is the authority. Zero trust applied to the runtime, not just the network.
What Nitro Enclaves do with custom silicon, Cipher does in software
The closest analogues to Server Enclave are AWS Nitro Enclaves, Intel SGX and Azure Confidential Compute. They solve the same problem — running code on infrastructure you do not fully trust — but they require specialised hardware, specific cloud providers and attestation workflows.
Cipher reaches the same outcome entirely in software — on any Linux server, at any hosting provider, on bare metal. No custom CPUs, no TEE-compatible instance types, no vendor lock-in. A $50-a-month dedicated server becomes a sealed enclave.
And when a server is lost, the recovery is not a restore but a fresh install: provision a new box, install the engine, and the environment pushes your whole stack back. Same code, same APIs, same sites.
Your code runs. Nobody gets in.
Walk through Enclave with your security team on a test server of yours — seal it, try the doors, unseal it from the app.