Skip to main content

nilCC Overview

What is nilCC?

nilCC (Nillion Confidential Compute) is a private compute platform where nodes perform developer-specified workflows within Trusted Execution Environments (TEEs). This enables general-purpose private computation over sensitive data through containerized applications.

Developers can deploy any Docker Compose application with hardware-guaranteed privacy and cryptographic proof of execution integrity, transforming standard workloads into verifiably secure computations.

Core Capabilities

  • Docker Compatibility: Run your Docker Compose application - databases, APIs, ML models, analytics pipelines
  • Hardware Security (CPU/GPU): AMD SEV-SNP (AMD Secure Encrypted Virtualization-Secure Nested Paging) provides memory encryption and isolation for CPU workloads. GPU-enabled machines support NVIDIA Confidential Compute with additional GPU attestation.
  • Cryptographic Verification: Hardware-generated attestation reports prove workload integrity. CPU configurations are verified through AMD SEV-SNP measurements, and GPU machines provide NVIDIA attestation tokens.
  • Complete Isolation: Each workload runs in its own Confidential VM, protected from host and other workloads
  • Resource Allocation: CPU and memory resources are tracked and allocated by nilcc-agent to prevent overcommitment. GPU resources are available on supported machines for enhanced computational capabilities.

Why Use nilCC?

Traditional cloud computing requires trusting the infrastructure provider with your code and data. nilCC eliminates this trust requirement by using hardware-level security that even the infrastructure provider cannot bypass, enabling you to process sensitive data with cryptographic proof of integrity.
We encourage you to extend these security guarantees to your users. Workloads running on nilCC cannot be accessed by the machine administrator or by the developer, powered by the same cryptographic attestation. By making the source code publicly available your users can also confirm the integrity of the workload and feel confident that their data is safe and secure.

How Does nilCC Work?

nilCC operates through a simple process: you submit a Docker Compose file, nilCC creates a secure Confidential VM to run it, and provides cryptographic attestation that proves your workload runs unmodified.

Confidential VMs (CVMs)

Confidential VMs (CVMs) are virtual machines that leverage AMD SEV-SNP to run workloads, in the form of docker compose files, in a secure and verifiable way. All CVMs include a Caddy instance that will act as a proxy to a specific container in the compose setup and will handle TLS certificate generation for it via ZeroSSL.

Example: nilCC Docker Compose for a Caddy-based API service

services:
web:
image: caddy:2
command: |
caddy respond --listen :8080 --body '{"hello":"world"}' --header "Content-Type: application/json"

This becomes a secure, attestable workload with automatic TLS and hardware protection.

Integrity and Verification

Confidential VMs provide a means to retrieve a hardware generated attestation, that can then be used to ensure that:

  • The contents of the filesystem at boot time are the expected ones
  • The virtual machine is running the expected docker compose file

dm-verity

The filesystem used to boot the VM is verified using dm-verity, which allows proving that its contents haven't been tampered with. The VM disk's merkle tree and root hash are verified during boot to ensure the filesystem hasn't been tampered with.

Attestation Reports

Attestation reports, as generated by AMD SEV-SNP, contain a measurement hash which is derived from:

  • The kernel being used
  • The initrd image used during boot
  • The Open Virtual Machine Firmware (OVMF) that VM uses
  • The parameters passed to the kernel when launching the VM
  • The number of vCPUs attached to the VM

Secure Boot and Workload Validation

nilCC ensures workload integrity through a secure boot process. The custom initrd image:

  • Mounts the dm-verity disk and ensures its integrity using the root hash provided as a kernel parameter
  • Creates a squashfs filesystem on a disk that is attached during boot and encrypts it via LUKS using a random key. This disk is mounted on /var to allow docker compose to work with a read-only root filesystem
  • Ensures the docker compose that's part of the workload is being ran by sha256-hashing the docker compose file and comparing it with the expected hash passed as a kernel parameter

Resources