Filling every memory channel on a v5 node satisfies Intel’s TDX gate, reaches peak DDR5-6400 bandwidth, and opens the largest SGX enclave the silicon supports. Three outcomes, one line item.
If you have a workload you cannot put on shared infrastructure, protected health information, financial records, a multi-party data collaboration, or a proprietary model’s weights and prompts, an Intel TDX Trust Domain on OpenMetal v5 hardware gives you a place to run it. Memory stays encrypted from the host, the host is a dedicated single-tenant server rather than a slice of someone else’s capacity, and OpenMetal holds HIPAA at the organizational level, which is what lets it sign a Business Associate Agreement. Confidential computing is a property of hardware you already lease at a fixed monthly cost, so there is no confidential-instance premium and no separate metered SKU to move the workload onto when the compliance requirement lands.
The decision that unlocks all of this is a memory decision, and it pays three times. Intel TDX will not initialize unless Slot 0 of every memory channel is populated, symmetrically across both sockets, with at least eight DIMMs per socket. That exact same full-channel population is what brings the node to its full DDR5-6400 bandwidth, and it is what frees enough system RAM to reserve a large SGX enclave. So the usual trade, pay for security or pay for performance, does not exist here. You fill the channels once and collect a trust boundary, peak memory throughput, and enclave headroom together.
Key Takeaways
- Confidential computing with no confidential-computing premium. Trust Domains run on a dedicated single-tenant server at a fixed monthly cost, backed by OpenMetal’s organizational HIPAA posture. There is no metered confidential-instance SKU to migrate onto. TDX is bare metal only: you run your own hypervisor, and it is not offered as a Hosted Private Cloud guest.
- One line item, three returns. Full-channel population satisfies Intel’s TDX gate, reaches peak DDR5-6400 bandwidth (roughly 410 GB/s per socket across eight channels), and makes room for the largest SGX enclave the CPU supports. Security and performance are not competing purchases on this platform.
- XL v5 arrives ready. It ships 1 TB as sixteen 64 GB modules, one per channel across both sockets, which satisfies the gate and runs full bandwidth in its shipped configuration. A regulated workload can land on it the day it racks, with no upgrade and no special order.
- Medium v5 and Large v5 are headroom, not a dead end. Both ship eight of sixteen slots filled, so at base they run about half their bandwidth and cannot initialize TDX. Filling them later delivers both, on the same node and the same platform, with nothing to migrate or re-architect.
- Large v5 is the tier for large protected datasets. Its processor supports an SGX enclave page cache of up to 512 GB per socket against 128 GB on Medium and XL, and reaching that reservation is one more thing the 1 TB fill buys. SGX is enabled by default and, unlike TDX, runs on both bare metal and the Hosted Private Cloud.
Why the memory subsystem is the gate
TDX is usually described as a CPU feature you switch on, and on Granite Rapids that framing hides the part that governs whether you can run it at all. TDX builds its protections on top of multi-key total memory encryption implemented in the integrated memory controllers, and the module needs every controller channel present and symmetric to manage encrypted memory and its metadata coherently. The platform firmware enforces this: until the first slot of every channel is filled, symmetrically across sockets and at eight DIMMs per socket minimum, the activation path is not exposed.
That changes how you specify a node. A half-populated server is not a TDX server with less capacity. It is a server where TDX is unavailable. You cannot buy your way to confidential computing by accepting a memory compromise, which is precisely why the gate and the bandwidth ceiling turn out to be the same purchase.
Which tier you buy, and what you get for it
XL v5 is the no-decisions option. It ships 1 TB as sixteen 64 GB modules across thirty-two slots, one DIMM per channel on both sockets. That configuration satisfies the TDX gate and runs at full DDR5-6400, so confidential workloads are available on day one and nothing needs to be ordered, scheduled, or swapped. If a compliance deadline is driving the purchase, this is the tier that meets it without a lead-time conversation. It also means the memory is already in the node and already inside the fixed monthly price: no component purchase sits between signing and running the workload.
Medium v5 and Large v5 let you buy for today and add the capability later. Both ship eight of their sixteen slots filled, which is four of eight channels per socket, so at base they run roughly half their potential bandwidth and cannot initialize TDX. Neither limitation is permanent. Large v5 ships 512 GB as eight 64 GB modules and has eight open slots, so populating them reaches a symmetric 1 TB. Medium v5 ships 256 GB as eight 32 GB modules, so its path replaces those with sixteen 64 GB modules to land on the same 1 TB. In both cases the node, the platform, and the deployment stay exactly as they are: no migration, no re-architecture, no different SKU. You size for the workload you have and cross the confidential-computing line when a workload actually requires it, collecting the bandwidth improvement on the way.
One variable is not fixed by the spec sheet. A later fill is a component purchase made at a later date, and RDIMM pricing and lead times move with the memory market rather than with your project schedule. OpenMetal quotes the upgrade when you order it. That cuts both ways, and which way depends on how certain the requirement is. If you already know a confidential workload is coming, or it has a date on it, buying a tier that ships populated puts the memory inside a fixed monthly cost today and collapses two purchases into one you can see now. If the requirement is real but unconfirmed, the Medium or Large v5 path is the better financial call precisely because you are not pre-buying 1 TB you may never need.
This is the same base-configuration behavior that shapes the wider generational story in what v5’s bandwidth upgrades actually unlock, carrying a second consequence on the confidential-computing side.
How far the memory scales, and the one trade to know
All three v5 tiers can be built out to 4 TB, which matters for in-memory databases and large analytics working sets that have nothing to do with confidential computing. Two qualifiers come with that figure. It requires special-order RDIMMs at a longer lead time rather than the 64 GB modules held in stock, sixteen 256 GB modules on Medium and Large v5 and thirty-two 128 GB modules on XL v5, and because those are special-order parts both the price and the lead time are quoted at the time of order rather than fixed in advance. And on XL v5, filling all thirty-two slots means two DIMMs per channel, at which point the memory negotiates down to DDR5-5200 from the DDR5-6400 of its shipped 1 TB configuration. The maximum-capacity build is not the maximum-bandwidth build.
There is a useful asymmetry in that. Because Medium v5 and Large v5 have sixteen slots against sixteen channels, their 4 TB build is still one DIMM per channel, so it keeps both full bandwidth and TDX eligibility. If you need maximum capacity and maximum bandwidth in the same node, those two tiers give you a path that XL v5 cannot.
Why 1 TB is the production line
Two thresholds coincide here. Intel’s architectural minimum for TDX is full-channel population. OpenMetal’s production tier for confidential workloads is 1 TB of RAM. On an eight-channel dual-socket platform with 64 GB modules, sixteen channels at 64 GB each is exactly 1 TB, so one fill satisfies both by design.
The reason 1 TB is the recommended tier rather than the minimum one is that confidential computing has fixed overheads which stop competing with your usable envelope once the envelope is large enough. The TDX module reserves per-page metadata, the PAMT, before any Trust Domain launches, roughly 1/256 of system RAM or about 4 GB on a 1 TB node. That proportion is constant, but on a smaller node it consumes a larger share of what you have before a workload starts, and every additional Trust Domain adds its own encryption and integrity-tracking overhead. Intel’s published overhead figures, in the low single digits for throughput-bound work and around 4.5% for memory-latency-sensitive benchmarks, were measured on a two-socket platform with 1 TB in sixteen 64 GB modules. Specify the same shape and those are the numbers that apply to your node, which is the difference between citing a vendor benchmark to a stakeholder and extrapolating from one.
When the enclave is the product: SGX and Large v5
TDX protects an entire virtual machine. Intel SGX protects an enclave inside an application, which is the right tool when you want to isolate one secret-handling routine rather than wrap a whole guest. Two properties decide the tier.
First, SGX is enabled by default and runs on both bare metal and the Hosted Private Cloud, so it is available in places TDX is not. Second, and no spec page frames this as a confidential-computing decision, the Large v5 processor supports an SGX enclave page cache of up to 512 GB per socket, four times the 128 GB on the Medium v5 and XL v5 processors, with a correspondingly larger multi-key encryption key space.
The enclave page cache is the protected memory an enclave runs in, and when a working set exceeds it the platform pages encrypted memory in and out at real cost. A larger cache means a larger protected dataset stays resident, which is what makes Large v5 the tier for SGX workloads with substantial protected working sets. The reservation comes out of usable system RAM, and Intel’s guidance is that up to roughly half of installed memory can be assigned to SGX, so a 512 GB enclave is reachable once the node is at 1 TB. Enclaves themselves run at the base configuration with no upgrade at all. The same fill that unlocks TDX and full bandwidth is what unlocks the full enclave, which is the third return on that single decision.
Where the boundary stops
The boundary runs here. TDX on OpenMetal is bare metal only: you run your own hypervisor on a dedicated single-tenant server and launch Trust Domains yourself. It is not offered as a guest on the managed Hosted Private Cloud. SGX runs on both.
Adding a GPU inside that boundary is possible on both OpenMetal GPU servers through NVIDIA Confidential Computing, which passes a single GPU into a TDX trust domain over an encrypted link, one GPU per confidential VM. The specific workload will need to be validated by the OpenMetal Engineering team, and it is delivered as an engineered build rather than a self-serve toggle. The deeper native path, where the GPU is admitted to the trust boundary through PCIe TEE-IO and Intel TDX Connect without bounce buffers, is not yet generally available. The architecture is covered in confidential GPU computing on OpenMetal.
For host enablement, OpenMetal publishes a guide to enabling Intel TDX on bare metal covering the hardware and symmetric-memory prerequisites, the BIOS settings involved, and post-boot verification of the CPU flag. Its scope stops at host enablement. Creating guest Trust Domains, GPU confidential computing, and attestation sit outside it, and attestation on OpenMetal is an engineering engagement today rather than a self-serve step.
The compliance boundary runs along a similar line. OpenMetal’s HIPAA posture is organizational, which is what supports a Business Associate Agreement. Data center certifications such as SOC 2 and ISO 27001 belong to the facility operators, so they are facility-level controls underneath your deployment rather than OpenMetal certifications. For a worked example of a confidential workload assembled from these pieces, see the walkthrough on running confidential AI inference on bare metal TDX servers. Per-tier configuration detail lives on the XL v5, Large v5, and Medium v5 hardware pages.
Which node your workload wants
- A confidential requirement that is known, or has a date on it. XL v5. Shipped 1 TB, TDX-ready, full bandwidth, nothing between the order and the first Trust Domain, and no component purchase left to make later.
- A requirement that is real but unconfirmed, or a smaller confidential footprint. Medium v5 or Large v5. You avoid pre-buying memory you may never need, and the same fill delivers TDX and full bandwidth later on the node you already run. The upgrade is quoted when you order it.
- An application enclave holding a large protected dataset. Large v5 at 1 TB. Its processor supports the largest enclave page cache in the lineup, and the fill is what makes that reservation available.
- Maximum capacity without giving up bandwidth. Medium v5 or Large v5 built to 4 TB, where sixteen slots against sixteen channels keeps one DIMM per channel and preserves both DDR5-6400 and TDX eligibility.
Talk to an architect
Choosing a tier comes down to mapping your trust model, whole-VM TDX isolation or in-application SGX enclaves, against the memory fill and enclave capacity each tier provides. Talk to an OpenMetal architect to size a v5 configuration against your confidential-computing requirements and confirm the upgrade path for your workload.
Talk to an OpenMetal architect

































