.png){kind=logo}
Deploy workloads that stay encrypted while they run, on any cloud, from one console
eMCP provisions confidential VMs, Kubernetes clusters and databases into AWS, Azure, Google Cloud, European clouds or your own hardware. Everything runs in your account, encrypted in use, with keys that are released only to environments that prove they're untampered.
Runs on AWS, Azure, Google Cloud, IONOS, STACKIT and your own hardware — on AMD SEV-SNP and Intel TDX silicon.
The layer that makes the hardware operable
Confidential computing hardware ships in every modern server, but operating it across clouds is the hard part. eMCP is the layer that makes it deployable, repeatable and provable.
Provisions confidential infrastructure
Launch confidential VMs from hardened blueprint images, confidential Kubernetes clusters with pod-level isolation, and encrypted-in-use databases — the same way on every supported cloud, instead of learning each provider's quirks.
Verifies before it trusts
Every workload gets an attested identity: cryptographic proof of what is running and that it hasn't been tampered with. Secrets and keys are released only against that proof. A modified or relocated workload gets nothing.
Keeps keys and secrets under your policy
Centralized secrets governance with rotation and audit trails, dynamic time-bound credentials for clouds and datastores, and an elastic virtual HSM for customer-held keys — bring your own key and hold your own key.
Operates it all from one place
One console and API for deployment, policy, attestation status and evidence across every environment. Audit artifacts come from how workloads actually run, ready when the auditor asks.
Connect your cloud
Create a least-privilege role in your AWS, Azure or GCP account and hand eMCP the credentials. Everything it provisions lands in your account, visible in your own console and logs.
Pick a blueprint
Choose a confidential VM image, a Kubernetes cluster profile or a database pattern. Blueprints ship secure-by-default, so the baseline is done before your first deploy.
Deploy, attest, run
The workload boots inside encrypted memory, proves its integrity, and only then receives its keys and secrets. From here it behaves like any other workload — except nobody operating the infrastructure can read it.
Sealed & attested
Six services, one guarantee
Every service runs encrypted in use, attestation-gated, on your cloud.
Hardened guest OS images running in encrypted memory on AMD SEV-SNP or Arm CCA machines.
Lift an existing sensitive application to the cloud without approval battles.
Clusters where pods are encapsulated as confidential VMs, with pod-level isolation for multi-tenant setups and reduced control-plane access paths.
A secure-by-default landing zone for containerized workloads, including VMware-exit migrations.
Managed MariaDB and PostgreSQL that stay encrypted while queries run, plus a confidential container registry.
Customer or patient data that legal won't allow on a standard managed database.
Central policy for static secrets, dynamic time-bound credentials that auto-revoke, HA vault clustering with agent-side delivery.
Replace scattered secrets in config files and CI variables with one governed store.
HSM-grade key custody running in confidential compute, with VM economics. Coexists with legacy HSM estates — no rip-and-replace.
Customer-held keys (BYOK/HYOK) required by a regulator or an enterprise customer.
Signing keys and pipeline secrets released only to attested build environments, protecting the software supply chain.
Prove to customers that releases are built and signed in verified environments.
Delivered by Buckypaper (confidential VMs), Dyneemes (confidential Kubernetes), vHSM, Vault and Nitride — all
operated through eMCP.
Your account. Your rules. Our control plane
eMCP deploys into your own cloud tenancy using a least-privilege identity you create and can revoke. There is no vendor-hosted account holding your infrastructure, which changes how procurement, audit and security review the platform.
Start small, grow into a platform
Most teams don't adopt confidential computing in one step, and eMCP doesn't ask them to. The same console covers each stage, so nothing gets thrown away as scope grows.
Keys first
Virtual HSM and vault for customer-held keys and governed secrets. Smallest footprint, immediate audit value.
Confidential VMs
Move a first sensitive workload into encrypted memory, unchanged.
Confidential Kubernetes
Standardize on a confidential-by-default cluster baseline for new and migrated services.
Full platform
Databases, CI/CD, AI workloads and multi-cloud operations under one policy and evidence model.
One console covers all four stages — nothing gets thrown away as scope grows.
Workload starts
Code, config and platform state measured by the CPU
Evidence produced
Hardware-rooted attestation report, signed
Policy checked
Nitride verifies the measurement against your policy
Keys released
vHSM and vault unseal — only now, only to this workload
Workload starts
Tampered image, injected container or rogue host
Evidence produced
Measurement does not match what you approved
Policy rejects
Mismatch logged with its reason, for the audit file
Nothing released
No keys, no secrets — the data stays ciphertext
What evaluators ask
What do I get on the free tier?
Enough to evaluate for real: deploy confidential VMs and try the console, attestation flow and secret delivery against your own cloud account. Production workloads move to a scoped pilot with our team.
Do my applications need code changes?
Usually none. Applications run unmodified inside confidential VMs, Kubernetes or databases. Secret delivery integrates through an agent or proxy — configuration, not a rewrite.
What's the performance overhead?
Memory encryption runs in hardware, so the overhead is small for most workloads and depends on the workload profile.
How is this different from the hyperscalers' own confidential VMs?
The hardware is the same; the operating model isn't. Hyperscaler offerings tie you to one cloud, leave attestation and key release for you to assemble, and keep key management adjacent to the same provider you're protecting against.
Which hardware does it require?
Any machine with AMD SEV-SNP or Arm CCA — available in current generations at every major cloud and available for on-prem hardware.
What happens if attestation fails?
The workload gets no keys and no secrets, and the failure is logged as evidence. That's the design: a tampered, modified or relocated environment cannot decrypt anything.
Can we run it fully on-prem or air-gapped?
Yes — used in sovereign and on-prem deployments where the control plane itself must stay inside your perimeter.
Spin up your first confidential VM_
Connect a cloud account, pick a blueprint, and see attestation-gated key release work — before you talk to anyone.
Want the deeper technical picture first? Read the docs
