# Single tenant hardware


On Enterprise, your team gets hardware of its own. The servers behind your
pools run your VMs and no one else's: no other customer's VM shares their
CPUs, memory, or disks.

Single-tenant hardware can be exe.dev's own servers, in our
[regions](/docs/regions), or servers in AWS. To run on servers in your own
cloud account or data center instead, see [BYOC](/docs/enterprise-byoc).

## Why

- **Defense in depth.** Every exe.dev VM is already isolated from its
  neighbors by KVM. Single-tenant hardware adds a second wall behind it: with
  no one else's VMs on the machine, a hypervisor escape or a side channel
  through shared CPU caches has no other customer's workload to start from.
- **Physical isolation.** Your VMs' disks are on NVMe drives that hold only
  your data, in servers that run only your work. That is a simple answer to
  give auditors and security reviews about where your data lives and what it
  shares a machine with.
- **No noisy neighbors.** Every core, every byte of memory bandwidth, and
  every IOPS of the local NVMe is yours, so performance is predictable.
- **Capacity on hand.** Pools on your hosts take effect immediately at any
  size a host can take, with no approval step, and creating a pool never
  falls back to shared hardware.

## How it works

Your hosts are assigned to your team. Every new pool the team creates is
placed on one of them automatically, so `pool new` takes no `--region`; the
host decides:

```
pool hosts                 # your hosts: region, status, largest pool each can take
pool new build --cpus=32   # placed on one of your hosts
```

Everything above the hosts works as described in
[Enterprise exe](/docs/enterprise): VMs and [pools](/docs/pools), the HTTPS
proxy and custom domains, integrations, teams and SSO, Shelley, and the CLI
and API.

## Getting started

Single-tenant hardware is part of [Enterprise exe](/docs/enterprise). Email
[support@exe.dev](mailto:support@exe.dev), and we'll size the hosts with you.