Safebox instances are not ordinary cloud servers. They are sealed, attested compute environments — cloned from a publicly auditable AMI, booted under TPM measurement, and designed so that not even the operator who runs the hardware can tamper with what executes inside. The trust model is structural, not policy-based. Understanding it requires a tour through every layer, from the hypervisor floor to the PHP process at the top.
The Foundation: Amazon Nitro and Hardware-Level Security
Safebox runs on AWS instances backed by the Nitro hypervisor, Amazon’s purpose-built bare-metal virtualization substrate. Nitro is not a general-purpose hypervisor bolted onto commodity hardware — it offloads networking, storage I/O, and security enforcement onto dedicated Nitro cards, isolating them from the instance entirely. This is what makes the first encryption layer automatic and unconditional.
RAM Encryption (Nitro, Not Enclave)
A common misconception is that secure compute requires AWS Nitro Enclaves — the isolated microVM sub-environment with no persistent storage and heavily restricted I/O. Safebox deliberately does not use Enclaves. Instead, it relies on platform-level memory encryption provided by Nitro itself: all DRAM on Nitro-backed instance families is encrypted by the hardware, with keys managed by the Nitro controller that the guest OS cannot observe or export. No application code is required to achieve this. Even a kernel-level attacker who somehow obtained a RAM dump would see ciphertext.
This is a cleaner threat model for a multi-tenant web stack than an Enclave, which imposes severe constraints (no GPU, no persistent storage, no standard system calls) that would make running PHP-FPM and Node.js workers impossible.
TPM Measured Boot
Safebox uses the vTPM (virtual TPM 2.0) that AWS began providing for EC2 instances in late 2025. On each boot, the TPM measures and extends Platform Configuration Registers (PCRs) with cryptographic hashes of:
- The kernel and initramfs
- The root filesystem state
- The Safebox binary and its encryption modules
- The result state of
finalize.sh(the final deterministic build step)
The PCR values are deterministic: if anyone rebuilds AMI 3 from the same inputs using the same build-manifest.json (which pins every RPM version, every Docker image hash, and every binary SHA-256), they will arrive at byte-identical PCR measurements. This is the auditor guarantee. Encryption keys are not baked into the AMI — they are provisioned post-attestation, released only when the remote attestation server confirms the PCR quote matches the expected values. An instance that booted tampered software simply never receives its keys.
EBS Encryption
Below the filesystem sits an AWS EBS volume encrypted with AES-256, key management delegated to AWS KMS. This is the second of three encryption layers and operates transparently at the block device level. Even a raw snapshot of the volume is useless without the KMS key.
The Filesystem: ZFS
On top of the encrypted EBS volume, Safebox runs ZFS — specifically a safebox-pool backed by the EBS block device. ZFS was chosen because it is the only mature filesystem that combines all of the following in a single coherent layer:
Copy-on-Write semantics. Every write produces a new block; no data is ever overwritten in place. This means instant, space-efficient snapshots and clones — you can clone a tenant’s entire database dataset in milliseconds for a staging environment, with no data duplicated until writes diverge.
Per-dataset AES-256-GCM encryption. This is the third encryption layer. Each tenant’s data subtree (safebox-pool/tenants/acme/) is its own encrypted ZFS dataset. A key compromise at one tenant’s layer does not cascade to others.
LZ4 compression at the block level, yielding roughly 2–3× storage efficiency on typical web application data with negligible CPU overhead.
Block-level deduplication across the Docker overlay2 layers. Multiple containers sharing the same PHP 8.2 base image (800 MB) store only one copy; each container’s writable layer is only its actual delta.
Checksums on every block, making silent data corruption detectable at read time — critical for a multi-tenant system handling uploaded files and database pages.
ZFS datasets map directly onto the multi-tenant directory structure: one dataset per tenant, one per app database, one for Docker overlay layers. ZFS snapshots become the foundation for Safebox’s backup pipeline, with XtraBackup streaming encrypted chunks out to decentralized storage.
The Web Stack: Nginx, PHP-FPM, Node.js
Nginx
Nginx serves as the front door — TLS termination, virtual host routing, and reverse proxy. Each tenant domain maps to a PHP-FPM unix socket for dynamic content and directly to disk for static assets. Nginx’s X-Accel-Redirect is used for protected file serving: PHP authenticates the download request, sets the header, and hands off to Nginx for zero-copy kernel sendfile() delivery — without exposing the real path to the client and without the file passing through PHP’s memory.
SSL/TLS Certificates
Safebox supports two certificate modes. For production deployments behind Cloudflare, Cloudflare Origin Certificates provide 15-year validity with Authenticated Origin Pulls (mTLS between Cloudflare’s edge and the origin), so the origin never exposes a public-CA cert directly. For deployments not behind a CDN, Let’s Encrypt certificates are obtained via certbot --nginx with automated renewal. In both cases, nginx is configured for TLS 1.2/1.3 only, with ssl_protocols TLSv1.2 TLSv1.3 and strong cipher suites.
PHP-FPM
PHP-FPM runs in per-tenant pool isolation. Each tenant gets a dedicated pool configuration:
- Runs as a dedicated Linux user (
tenant1,tenant2, …), enforced at the OS level - Communicates with nginx via a unix socket owned exclusively by that user and nginx
open_basedirrestricts filesystem access to the tenant’s own directories- Process manager set to
ondemand: workers spin up on demand to a configurable maximum (default 3) and shut down after 5 minutes of idle — no resident processes for inactive tenants disable_functionsremovesexec,shell_exec,system,proc_open, and related syscall wrappers
This is not container-based isolation for PHP — it is Linux user-level isolation with chroot-like filesystem constraints, lighter weight than containers and sufficient for the threat model where the AMI itself is already sealed.
Node.js
Each tenant also gets a Node.js process running as the same tenant user, listening on a localhost port. PHP communicates with it over that internal socket. Node.js handles workloads that benefit from asynchronous I/O and long-running event loops: real-time streaming, websocket connections, background job processing, and Safebox’s own orchestration layer (Workflows → Workloads → Tasks).
The Node.js process implements the same idle-shutdown behavior as PHP-FPM: a setInterval check clears the process after 5 minutes without activity. Systemd unit files with Restart=on-failure bring it back on the next request.
MariaDB
A single MariaDB instance serves all tenants, with per-app databases (acme_website, acme_blog, beta_api) and per-app credentials. The innodb_open_files and table_open_cache settings are tuned for many concurrent small databases. MariaDB’s data directory sits inside a ZFS dataset, so InnoDB pages are encrypted at the filesystem layer (the third encryption tier) before they ever reach EBS.
The Software Stack: OpenSSL and Cryptographic Plumbing
OpenSSL is present throughout: TLS session negotiation in nginx, the openssl CLI for certificate inspection and key operations during provisioning, and as the underlying cryptographic backend for PHP’s openssl_* functions and Node.js’s crypto module. The Safebox OCP (OpenClaiming Protocol) layer performs AES-GCM encryption with the format IV(12) ‖ ciphertext ‖ tag(16), HKDF key derivation, and secp256k1 signing — all ultimately delegated to OpenSSL primitives.
Supporting tools baked into the AMI include ripgrep for fast log and codebase search, rsync for file operations, ffmpeg and lame for media processing workloads, and the full set of standard Amazon Linux 2023 cryptographic utilities pinned at specific versions in build-manifest.json.
The Three Encryption Layers, Summarized
RAM → Nitro hardware encryption (automatic, unconditional)
Disk → EBS AES-256 / KMS (block device level)
Files → ZFS AES-256-GCM per dataset (filesystem level)
Even in a scenario where an attacker gains root access post-attestation, the keys unsealed by the TPM are the only path to plaintext. Without a valid PCR quote matching the audited AMI, the attestation server never releases them.
Cloud Equivalent Technologies: Provider Comparison
The Safebox architecture depends on four platform capabilities: a trusted machine image system (AMI equivalent), TPM-based measured boot and attestation, hardware memory encryption, and encrypted block storage. Here is how each major cloud provider maps to those requirements.
| Capability | AWS | GCP | Azure | Oracle Cloud | IBM Cloud |
|---|---|---|---|---|---|
| Sealed Machine Image | AMI (Amazon Machine Image) — byte-identical, sharable, version-pinned snapshots of root volumes | Custom Images / Compute Engine Images — equivalent; can be shared and version-tagged | Azure Managed Images / Shared Image Gallery — equivalent; supports versioning and region replication | Custom Images / OCI Compute Images — equivalent | Custom Images via IBM Cloud VPC |
| TPM / Attestation | vTPM 2.0 for EC2 (GA late 2025); PCR quotes via aws ec2 get-instance-uefi-data; integrates with AWS Certificate Manager Private CA |
Shielded VMs — vTPM 2.0 + Secure Boot + Integrity Monitoring; attestation via gcloud compute instances get-shielded-identity |
Trusted Launch VMs — vTPM + Secure Boot + Measured Boot; attestation via Microsoft Azure Attestation service | Measured Boot with vTPM on OCI — available on E4/E5 flex shapes; integrates with OCI Key Management | IBM Hyper Protect Virtual Servers — LinuxONE-based, hardware-enforced attestation; more enterprise-focused than commodity VMs |
| Confidential Compute | Nitro RAM encryption (platform-level, all instance types); Nitro Enclaves (isolated microVM, restricted) | Confidential VMs — AMD SEV-SNP or Intel TDX; memory encryption at hardware level; attestation report includes memory integrity | Azure Confidential VMs — AMD SEV-SNP or Intel TDX; Azure Confidential Computing with Attestation | OCI Confidential Computing — AMD SEV on E4 shapes; memory encryption with hardware-managed keys | IBM Hyper Protect Services — Z-architecture Secure Execution; memory encryption is hardware-enforced at chip level |
| Encrypted Block Storage | EBS with AES-256, KMS-managed keys; encryption by default option | Persistent Disk encryption — default at-rest encryption; CMEK (Customer-Managed Encryption Keys) via Cloud KMS | Azure Managed Disks — Server-Side Encryption (SSE) with platform or customer keys; Azure Disk Encryption (BitLocker) option | OCI Block Volumes — AES-256 at rest, Oracle-managed or Customer-Managed Keys (CMEK) | IBM Cloud Block Storage — AES-256 at rest with provider or customer-managed keys via Key Protect |
| Secure Boot | UEFI Secure Boot on Nitro instances (opt-in) | Shielded VMs include Secure Boot by default | Trusted Launch includes Secure Boot by default | Secure Boot available on OCI Shielded Instances | Secure Boot on IBM Cloud VPC bare metal and virtual servers |
| Key Management / HSM | AWS KMS + AWS CloudHSM; KMS integrates natively with EBS, RDS, S3 | Cloud KMS + Cloud HSM; integrates with Persistent Disk CMEK | Azure Key Vault (software and HSM tiers); Dedicated HSM service | OCI Vault + OCI Dedicated KMS; integrates with Block Volume CMEK | IBM Key Protect (software) + IBM Cloud HSM (FIPS 140-2 Level 4 on Z hardware) |
| Immutable / Reproducible Build Pipeline | AWS Image Builder — automated, version-pinned AMI pipelines; integrates with Systems Manager | Cloud Build + Packer — standard approach; no native “Image Builder” equivalent | Azure Image Builder — native VM image automation service | OCI Images built via Packer or custom tooling; no native image builder service | IBM VPC custom images; Packer-based pipelines common |
| Notes | Safebox’s native platform. vTPM + Nitro memory encryption is the reference implementation. | Strongest out-of-the-box attestation story after AWS; Shielded VMs are default-on for many workloads. | Good attestation support; AMD SEV-SNP confidential VMs are production-grade. | Competitive on price; AMD SEV confidential compute available but ecosystem smaller. | Strongest hardware security guarantees (Z-architecture), but least standard ecosystem; best fit for regulated industries. |
What This Stack Achieves
The combination is not accidental. Each layer addresses a distinct attack class:
- Nitro RAM encryption defeats cold-boot and hypervisor-level memory inspection.
- TPM measured boot + attestation defeats supply-chain compromise of the AMI and operator-side tampering after deployment — the two highest-risk attack categories in Safebox’s threat model.
- EBS encryption defeats physical media theft or snapshot exfiltration.
- ZFS per-dataset encryption provides tenant isolation even within a compromised instance.
- Linux user isolation for PHP-FPM and Node.js defeats cross-tenant code execution without requiring containers for each tenant.
- No SSH in production AMI, no package manager eliminates the entire class of runtime software injection attacks.
The result is a stack where security is not a configuration choice an operator makes — it is the only thing the machine can do.