Self-Hosted Confidential Computing: Gramine vs Occlum vs Enarx TEE Platforms

Confidential computing uses hardware-based Trusted Execution Environments (TEEs) to protect data while it is being processed. Unlike encryption at rest and in transit, TEEs shield data in use — preventing even the host operating system, hypervisor, or cloud provider from accessing sensitive workloads. Three open-source platforms lead this space: Gramine, Occlum, and Enarx. Each takes a fundamentally different architectural approach to enabling confidential computing for self-hosted deployments.

What Is Confidential Computing?

Confidential computing isolates sensitive computation inside a hardware-protected CPU enclave. The enclave encrypts its memory contents, ensuring that data being processed cannot be read by external processes, the OS kernel, or a compromised hypervisor. This closes the “data in use” gap that traditional encryption cannot address.

Intel SGX (Software Guard Extensions) was the first widely adopted TEE, providing enclaves with encrypted memory pages. AMD SEV (Secure Encrypted Virtualization) takes a different approach by encrypting entire virtual machines. Intel TDX (Trust Domain Extensions) extends the VM-level model to cloud-native workloads. The open-source platforms discussed here primarily target SGX and emerging TDX support.

Architecture Comparison

Gramine: Library OS for SGX

Gramine (formerly Graphene) is a lightweight library OS that allows unmodified Linux applications to run inside Intel SGX enclaves. It intercepts system calls and maps them to the SGX enclave environment, providing the illusion of a full Linux OS inside the constrained enclave memory.

Key strengths:

• Runs existing Linux binaries without source code changes
• Supports multi-process applications (fork, exec, pipes)
• Mature project with the longest development history
• Active community and enterprise backing

Typical deployment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Install Gramine on Ubuntu
echo "deb [arch=amd64] https://packages.gramineproject.io/apt $(lsb_release -cs) main" |   sudo tee /etc/apt/sources.list.d/gramine.list
curl -fsSL https://packages.gramineproject.io/gramine-keyring.gpg |   sudo tee /etc/apt/keyrings/gramine-keyring.gpg > /dev/null
sudo apt update
sudo apt install gramine

# Build a manifest for an existing application
gramine-sgx-gen-manifest ./myapp.manifest.template ./myapp.manifest
gramine-sgx-sign --manifest ./myapp.manifest --output ./myapp.manifest.sgx
make -f Gramine/Makefile

Docker deployment:

1
2
3
4

FROM gramineproject/gramine:latest
COPY ./myapp /app/
COPY ./myapp.manifest.sgx /app/
ENTRYPOINT ["gramine-sgx", "/app/myapp"]

Occlum: Memory-Safe LibOS in Rust

Occlum is a library OS written in Rust that targets Intel SGX with a focus on memory safety and a smaller trusted computing base (TCB). By using Rust’s ownership model, Occlum eliminates entire classes of memory safety vulnerabilities that could otherwise compromise the enclave.

Key strengths:

• Memory-safe TCB through Rust’s type system
• Smaller attack surface than C-based alternatives
• Supports multi-process with fork/exec
• Built-in file system encryption inside enclaves

Typical deployment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Build Occlum from source
git clone https://github.com/occlum/occlum.git
cd occlum
make submodule
make install

# Create an Occlum instance and build a secure enclave
occlum new my_secure_app
cd my_secure_app
# Copy binaries into the image
mkdir build/bin && cp /usr/bin/python3 build/bin/
# Build the Occlum filesystem image
occlum build
# Run inside SGX enclave
occlum run /bin/python3 --version

Docker-based development:

1
2
3
4
5
6
7

FROM occlum/occlum:0.29.6-ubuntu20.04
WORKDIR /root
RUN occlum new /root/occlum_instance
COPY ./app /root/occlum_instance/build/bin/
WORKDIR /root/occlum_instance
RUN occlum build
ENTRYPOINT ["occlum", "run", "/bin/app"]

Enarx: Confidential Computing with WebAssembly

Enarx takes a fundamentally different approach. Instead of running Linux binaries inside SGX enclaves, Enarx compiles applications to WebAssembly (WASM) and executes them inside confidential VMs powered by AMD SEV, Intel TDX, or IBM Secure Execution. This provides stronger isolation (entire VM encryption) and broader hardware support.

Key strengths:

• Hardware-agnostic: supports AMD SEV, Intel TDX, IBM Secure Execution
• WebAssembly provides language-independent execution
• No SGX memory size limitations (VM-level instead of enclave-level)
• Future-proof for post-SGX hardware

Typical deployment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Install the Enarx keeper (runtime)
cargo install enarx

# Compile a Rust application to WASI
cargo build --target wasm32-wasi --release

# Run inside a confidential VM (automatic attestation)
enarx run ./target/wasm32-wasi/release/myapp.wasm

# Deploy with a keepconfig for production
enarx keep --help

Docker Compose for Enarx development:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

version: "3.8"
services:
  enarx-dev:
    image: enarx/enarx:latest
    volumes:
      - ./wasm-app:/app
    working_dir: /app
    command: ["run", "./myapp.wasm"]
    # Note: production requires KVM /dev access
    devices:
      - /dev/kvm

Choosing the Right Platform

The choice between these three platforms depends on your hardware, application stack, and isolation requirements:

• Choose Gramine if you have Intel SGX hardware and need to run existing Linux applications without modification. It is the most mature option with the widest application compatibility.
• Choose Occlum if memory safety is a top concern and you want a smaller trusted computing base. Rust’s safety guarantees make Occlum attractive for security-critical deployments.
• Choose Enarx if you need hardware flexibility beyond SGX, want to avoid enclave memory limitations, or are building new applications that can target WebAssembly. It is the most future-proof option as confidential VM support expands.

Why Self-Host Confidential Computing?

Running confidential computing workloads on your own infrastructure gives you complete control over the attestation process, key management, and enclave lifecycle. When you self-host:

Data sovereignty: Your sensitive workloads never leave your physical hardware. Even if a cloud provider’s hypervisor is compromised, your enclave-protected data remains unreadable. Self-hosting eliminates the shared-tenant risk inherent in public cloud confidential computing offerings.

Attestation control: You manage the entire attestation chain — from Quote Generation to verification — without relying on third-party attestation services. This is critical for regulated industries where the attestation verifier must be under your administrative control.

Cost predictability: Cloud-based confidential computing instances carry premium pricing. Self-hosting on SGX-capable hardware eliminates per-hour enclave premiums and provides predictable infrastructure costs for sustained workloads.

Compliance alignment: Many regulatory frameworks (HIPAA, PCI-DSS, FedRAMP) require specific controls around data processing environments. Self-hosted TEE deployments let you implement exactly the controls your compliance program demands, without negotiating cloud provider shared responsibility boundaries.

For broader container security strategies, see our container runtime security comparison and supply chain security guide. If you are also hardening your container images, check our container security hardening guide.

FAQ

What is the difference between a library OS and a confidential VM?

A library OS (like Gramine and Occlum) runs inside a CPU enclave and provides just enough OS functionality for a single application. A confidential VM (like Enarx’s target) encrypts an entire virtual machine, providing stronger isolation but requiring VM-level hardware support (SEV, TDX). Library OSes have lower overhead but are limited to enclave memory sizes.

Do I need special hardware for confidential computing?

Yes. Gramine and Occlum require an Intel processor with SGX support (most 8th-gen+ Intel Xeon and Core processors). Enarx requires AMD EPYC with SEV, Intel with TDX, or IBM Z with Secure Execution. Verify hardware support with cpuid or /dev/sgx device presence before deploying.

Can I run any application inside a TEE?

Gramine and Occlum can run most unmodified Linux binaries, but applications requiring large memory footprints may exceed SGX enclave limits (typically 128 GB max EPC). Enarx requires applications to be compiled to WebAssembly (WASI target). Database workloads, web servers, and cryptographic services are common candidates.

How does remote attestation work?

Remote attestation generates a cryptographic quote proving that code is running inside a genuine hardware enclave. The quote includes a measurement of the enclave’s contents, signed by the CPU. A remote verifier checks this signature against the hardware manufacturer’s attestation keys to confirm the enclave is authentic and unmodified.

Is confidential computing production-ready?

Gramine is the most production-ready option with enterprise deployments in finance and healthcare. Occlum is actively developed but has a smaller deployment base. Enarx is newer and evolving rapidly as TDX hardware becomes more widely available. All three are open-source and suitable for evaluation deployments.

What happens if the enclave is compromised?

Hardware TEEs are designed to be tamper-resistant at the silicon level. If an enclave is compromised, it typically indicates a hardware-level vulnerability (e.g., Foreshadow, CacheOut). Mitigations are released via microcode updates. Self-hosting lets you apply these updates on your own schedule without waiting for cloud provider rollouts.