Compute that cannot
see your data.
The hardware that used to hide behind enterprise sales calls is now one click away: deploy a WebAssembly app onto a confidential enclave equipped with a flagship NVIDIA GPU, straight from your browser. Pay per second, only while it runs: no subscription, no minimums. Then check the cryptographic attestation yourself before you send a single byte of data.
Don't trust the operator. Measure it.
Enclave runs your WebAssembly app inside a hardware-isolated, attested enclave with a confidential GPU wired into it, so the operator can't read your memory, your keys, or your traffic, and you don't have to take our word for it. Every claim on this page is something you can check yourself, in a signed attestation or a public record. We're equally explicit about the part that isn't hardware-enforced: how tenants are kept apart from each other on a shared GPU. See exactly how isolation works ↓
Trustless
Each enclave produces a CPU attestation report (AMD SEV-SNP on today's fleet) and an NVIDIA GPU attestation report. Verify them client-side against the measurements published on EnclaveHost/enclave releases, then connect.
Pay-as-you-go
No subscription, no seats, no sales call: sign in with a passkey and add credit, or bring your own keys and pay directly. Either way a payment buys prepaid runtime, burned per second while your deployment runs, and for paid apps the publisher's share is delivered the same instant. Payments are final: unspent time survives a stop but can't be withdrawn, so fund small and top up as you go.
Browser-native
The whole API is CORS-enabled. Spin up a server, stream logs, and pull attestation from front-end JavaScript. No backend required.
Real GPUs
Whole flagship NVIDIA GPUs in confidential-computing mode, wired into your Wasm app through a GPU interface. Deploying is two dials - a GPU share and a CPU share - floored at the minimums the app's declared specs imply. How tenants share a card →
Five calls, start to finish.
The path from zero to a verified GPU endpoint. Click a step to see exactly what crosses the wire.
What "trustless" actually means here.
"Trustless" isn't a slogan. It's a chain of measurements that ends in your browser. Walk each link to see what gets verified and why the operator can't fake it.
The CPU (AMD SEV-SNP on today's fleet) and the NVIDIA GPU hold keys fused at manufacture. Enclave can't extract or forge them. The silicon vendor (AMD or NVIDIA, Intel on a TDX host) is the root of trust, not the operator.
On boot the AMD secure processor signs a report over the launch measurement: a SHA-384 digest binding the firmware, the kernel, and the exact runtime image. Change one byte and it changes. Your app is deliberately not in this boot measurement: it arrives later by CID, and the measured runtime refuses bytes that don't hash to the CID in your on-chain deployment record. The attestation reports the app's CID and states exactly what covers it; it never pretends the boot quote does. (An Intel TDX host tells the same story via a DCAP quote over MRTD + RTMRs.)
With confidential computing on, the GPU signs an attestation report over your nonce, proving CC mode, driver, and vBIOS before any data reaches VRAM. Check it against NVIDIA's NRAS or nvtrust.
The enclave generates its TLS keypair in sealed memory and folds the public-key hash into the quote's report_data. The private key never leaves the boundary, so the operator can't sit in the middle.
Tinfoil's open-source verifier runs the whole chain client-side: hardware report against the vendor root, Sigstore provenance of the release, measurement comparison, TLS binding. The API's verification.selfCheck is the enclave running these same steps on itself: a labeled diagnostic, because trust only counts when YOUR client computes it. Try it live below.
Don't take this page's word for it: run the check now
Your browser loads Tinfoil's open-source verifier (@tinfoilsh/verifier) and fetches the attestation of one live enclave - the fleet's gateway nominates an active one, and the verdict names exactly which - over your own connection. It validates the hardware report up to the silicon vendor's root of trust (AMD SEV-SNP on today's fleet; the steps below name the technology the enclave actually presented), verifies the release's Sigstore code provenance against the public EnclaveHost/enclave repo, and compares the two measurements. Exactly what the API's verify field tells every client to do - and what your dashboard re-runs against the specific enclave each deployment lands on.
The verifier module is served from this site itself (same-origin, version-pinned), not a third-party CDN; the Sigstore provenance bundles and the silicon vendor's certificate collateral (AMD KDS) it checks come through Tinfoil's CORS proxies. Fully independent path: tinfoil attestation verify -e <enclave-host> -r EnclaveHost/enclave, via tinfoil-cli - swap in any enclave's host to put the rest of the fleet through the same check.
Two boundaries. One is hardware. One is not. We tell you which.
Most "confidential GPU" pitches blur these together. Enclave keeps them separate because they're enforced by different things and carry different guarantees. Here is precisely what protects you, and from whom.
You vs. the operator
Your enclave runs in a CPU TEE (AMD SEV-SNP on today's fleet) with the GPU in NVIDIA confidential-computing mode. The CPU↔GPU link is encrypted and the GPU is walled off from the host. Enclave, the operator, cannot read your VRAM, RAM, keys, or traffic. This is enforced by hardware and proven by an attestation you verify in your browser before sending data. This is the strong guarantee, and it's the one you can check cryptographically.
You vs. other tenants
CC seals the whole GPU as a single trust domain and disables MIG, so there's no hardware partition between tenants on one card. We isolate tenants with two software layers, and each guards a different side. On the CPU, each tenant's app runs inside a WebAssembly sandbox (memory-safe, no ambient authority, no host filesystem or environment). On the GPU, the sandbox does nothing; kernel execution is separated by the dedicated OS worker process each tenant gets: separate processes get separate GPU address spaces, mediated by the shared NVIDIA driver. Those boundaries, not a hardware slice, are what keep tenants apart, and we don't pretend otherwise.
What the Wasm sandbox and process boundary actually buy you · every GPU-level point below was measured on our own hardware
- No host reach. The Wasm app can't open files, read the host environment, spawn processes, or make outbound connections. WASI grants it only the HTTP socket the runtime serves it on. There's no shell and no SSH, anywhere: a Wasm app isn't an OS, so the usual container-escape surface simply isn't there, and the platform ships no SSH channel at all - no sshd runs in the enclave and nothing installs keys. The only ways in are the HTTP data path and the ports an app declares.
- No cross-tenant reads. Separate processes get separate GPU address spaces. A kernel in one tenant's process that tries to read another tenant's memory faults. The address simply isn't mapped. (Verified: the cross-process read attempt raised an illegal-access fault.)
- Blast radius of one. A tenant whose kernel crashes or runs illegal memory access takes down only their own worker. A co-tenant running on the same GPU kept executing without a single error, and the GPU stayed healthy. (Verified under a live fault.)
- Memory zeroed before reuse. The driver hands VRAM pages to a process only zeroed, so one tenant's residue is never observable to the next. Full disclosure about what our test does and doesn't show: zero-on-allocation is stock driver behavior, so "a fresh allocation read back zeroes" wouldn't prove much on its own. What we verified is that the property holds in the case that matters: under CC, after a tenant wrote ~117 GB and was killed without cleaning up, another process's fresh allocation came back fully zeroed. Whether the driver scrubs at exit or on allocation is its implementation detail; dirty pages crossing tenants is the failure, and it didn't happen.
- Fair share, not free-for-all. Each worker is capped to its purchased compute share so one tenant can't starve the GPU, and a watchdog kills any worker that exceeds its slice or hangs.
What we do not claim
Inter-tenant isolation is enforced by the WebAssembly sandbox, the operating system, and the NVIDIA GPU driver, the one component every tenant's app passes through to reach the card. So tenants are isolated from each other at the sandbox-and-process level, modulo the integrity of that shared driver, not by per-tenant hardware partitioning (which this GPU generation does not offer with confidential computing on). If your threat model requires hardware-enforced isolation from other tenants specifically, run a dedicated full-GPU deployment instead of a shared one. Isolation from us, the operator, is hardware-enforced and attested either way.
Metered per second. Pay as you go.
Deploying is two dials - what you rent - and two rates - what you pay. Prepaying buys runtime by the second; the instance runs until that time is used up, and you top up to extend it. Payments convert straight into runtime - for apps that charge a publisher fee, that share goes straight to the publisher - and are final. Unspent time stays on the deployment's public record (stop now, resume later) but isn't withdrawable, so fund in small top-ups.
0-100% of one GPU card. VRAM and compute move together: each percent buys ≈1.4 GB VRAM and ≈9.9 TFLOPS. 0% = a CPU-only app.
0-100% of the node's vCPU+RAM: each percent buys ≈0.16 vCPU, ≈0.64 GB RAM, ≈10 GFLOPS (a whole node is roughly a thousandth of a card's FLOPS). Your app's memory cap is exactly this slice of the node's 64 GB.
The VRAM, compute, and RAM an app declares in the catalog set each dial's minimum: spec ÷ server spec (140.4 GB / 989 TFLOPS per card; 64 GB / ~1000 GFLOPS per node), larger axis wins, rounded up to a whole percent. An app declaring 494 TFLOPS can't deploy below a 50% GPU share even if it needs 2 GB of VRAM - you can't occupy an axis without paying for it.
A GPU app's GPU share must be at least its CPU share (its CPU slice rides on the card's node) - so a 100%-GPU, 10%-CPU tenant leaves 90% of that node for CPU-only apps. Unsold CPU on a GPU node is never stranded. Shares are runtime-enforced software caps, not hardware MIG partitions.
price = GPU% × $6/hr + CPU% × $3/hr · metered per secondOne honest rounding note: the per-second rate is settled in whole millionths of a dollar, rounded up - so the very smallest slices meter a hair above the formula (a 1%-CPU app runs at $0.0324/hr rather than $0.0300). Every estimate shown on the deploy pages already includes this. Some store apps also charge a small hourly publisher fee - capped by the platform, shown in the rate before you pay, and paid straight to the app's publisher.
| Example | GPU share | CPU share | What the shares grant | Per hour | Per second |
|---|---|---|---|---|---|
| CPU-only | 0% | 10% | no GPU · 6.4 GB RAM / 1.6 vCPU | $0.30 | $0.000084 |
| Slice | 10% | 5% | ~14 GB VRAM / ~99 TFLOPS · 3.2 GB RAM | $0.75 | $0.000209 |
| Quarter | 25% | 5% | ~35 GB VRAM / ~247 TFLOPS · 3.2 GB RAM | $1.65 | $0.000459 |
| Half | 50% | 10% | ~70 GB VRAM / ~495 TFLOPS · 6.4 GB RAM | $3.30 | $0.000917 |
| Full GPU | 100% | 10% | 140.4 GB VRAM / 989 TFLOPS · 6.4 GB RAM | $6.30 | $0.001751 |
Example points on a continuous scale, not a fixed menu - the dials move in whole-percent steps. A Full GPU deployment (100%) is the option when you want no co-tenants on the card at all: it's the only configuration where isolation from other tenants is also hardware-enforced. On a shared card, tenants are isolated from each other at the sandbox-and-process level (how →) and always isolated from the operator by confidential computing.
Who's behind this.
Enclave is designed so you never have to take the operator's word for anything - but you should still know whose word you're not taking. Enclave is built and operated by Enclave Host, Inc.
Enclave Host, Inc.
The company behind Enclave. Payments to it settle in the open on a public record, and its enclaves prove what they're running before you send them a byte - the whole point is that "trust us" never has to enter the conversation.
Steven Batchelor
Founder & CEOSteven is a certified application architect focused on serverless architecture, with an extensive consulting background serving large enterprise clients and a passion for decentralized systems. He designs and builds Enclave hands-on: the attested enclave stack, the settlement contracts, and the site you're reading. Based in Arizona.