Confidential compute, made simple

There are three states your data lives in: at rest, in transit, and in use. The first two have been solved for years. Disk encryption protects data at rest. TLS protects data in transit. But the moment a workload starts running, its data is decrypted into memory and sits there in the clear, fully exposed to the host underneath it.

That third state, data in use, is the one most platforms leave unguarded. It is also the one that matters most in contested environments, on shared infrastructure, and anywhere you cannot fully trust the operator, the hypervisor, or physical access to the machine.

Confidential compute closes that gap. Starlight makes it something you can actually turn on.

What confidential compute does

Confidential compute runs your workload inside a trusted execution environment built into the processor. The memory belonging to that workload is encrypted with a key held by the CPU and never exposed to the host, the hypervisor, or any other tenant on the box. Computation happens on data that stays protected the entire time it is in use.

The hardware does the heavy lifting here. Intel TDX and AMD SEV-SNP both provide this capability at the silicon level. The problem has never been whether the protection exists. The problem is that turning it on has been painful.

Why almost nobody uses it

Standing up confidential compute the hard way means lining up a long chain of dependencies. You need a CPU that supports it. You need the right firmware settings enabled. You need kernel support, a hypervisor configured correctly, guest images built to run inside a trust domain, and an attestation flow to prove the environment is genuine before you trust it with anything sensitive.

Miss one link and the workload either fails to launch or, worse, runs without the protection you assumed it had. The result is that the capability ships on enormous amounts of hardware already in the field and sits switched off, because the path to using it is too steep.

Starlight detects it for you

Starlight starts by answering the question that usually takes an engineer an afternoon: does this machine support confidential compute, and is it actually enabled?

When Starlight comes up on a node, it inspects the platform and detects whether confidential compute is available and active in firmware. If the capability is present, Starlight knows it. You do not probe CPU flags, parse firmware tables, or maintain a spreadsheet of which nodes in your fleet are capable. Starlight handles the discovery and exposes the result as a property of the node.

From there, protecting a workload becomes a deployment decision rather than an infrastructure project.

One workflow, three kinds of workload

The thing that makes Starlight different is that confidential compute is not bolted onto one narrow use case. It runs through the same simple deployment model regardless of what you are running.

Virtual machines launch as confidential VMs through the Starlight API and libvirt, with their memory protected by TDX or SEV-SNP. Containers run confidentially through Podman with krun and libkrun, so a container gets the same memory protection a VM would. MicroVMs come up the same way through krunvm when you want a tighter, faster boundary. And AI inference, served through vLLM, runs inside that same protected envelope.

You describe the workload. Starlight places it on a capable node and brings it up with confidential compute protections in force. The complexity that normally lives between intent and a running protected workload is absorbed by the platform.

Confidential AI, not just confidential infrastructure

The AI case deserves its own mention, because it is where data in use gets most dangerous. When a model runs inference, both the model weights and the data being fed through it sit in memory in plaintext. On classified or sensitive workloads, that is exactly the material an adversary wants.

Running vLLM inside a Starlight confidential environment means the weights and the prompts and the results processed through them are protected in memory the entire time. You can put a model to work on sensitive data without exposing either the model or the data to the underlying host. For defense and intelligence workloads at the edge, that is the difference between an AI capability you can deploy and one you cannot.

What you are protected against

The clearest threat confidential compute defeats is whole data extraction. An adversary with host level access, a compromised hypervisor, a malicious operator, or physical access to the machine, can dump the entire memory of a running workload and walk away with everything in it: keys, credentials, model weights, and plaintext data.

Against a confidential workload, that memory dump yields ciphertext. The encryption key never leaves the processor, so the contents of the workload stay protected even from someone who owns the box it runs on. The same boundary blunts a whole class of related attacks that depend on reaching into a workload's memory from the outside.

That assurance matters most exactly where Starlight is built to operate: disconnected, degraded, and contested environments, on hardware you do not physically control, where the people and systems around your workload are not part of your trust boundary.

The point

Confidential compute has been available and underused for years because the on-ramp was too hard. Starlight removes the on-ramp. If the hardware can protect data in use, Starlight detects it and lets you deploy virtual machines, containers, and AI inside that protection through one simple workflow. The hard part is done by the platform. What you are left with is a deployment that keeps your data protected even while it is being used.