# Prerequisites

Gather these before you begin. The install will not succeed without them.

## Cloud and compute

* **Three AWS sub-accounts**, one per MPC shard - sub-account isolation is the security boundary, so a single account compromise exposes at most one Key Store + one Policy Server (below the MPC threshold). For non-production testing the example Terraform can also run all shards in one account (or two), with a correspondingly weaker boundary - never ship that shape to production.
* **Nitro-enclave-capable EC2 instance types** for the Key Store node groups. Non-burstable, non-metal instances with at least four vCPUs qualify; `c5.xlarge` and `c7i.2xlarge` are tested configurations.
* AWS CLI configured with named profiles for all three sub-accounts (AWS SSO recommended; long-lived access keys in Terraform state are an anti-pattern).

## Databases

One managed RDS PostgreSQL instance per sub-account. The chart expects three logical databases:

| Database | Required on |
|---|---|
| `mpc_ks_db` | All three clusters |
| `policy_db_N` | All three clusters |
| `orchestrator_db` | Hub cluster only |

If you use the example Terraform, it provisions these automatically and an in-cluster bootstrap Job creates the application role and databases. If you bring your own databases, create the databases and supply the connection strings as Helm values.

## Encryption keys

One symmetric AWS KMS key per sub-account, used by the Key Store storage encryptor to wrap MPC key shares before persistence. The example Terraform creates these keys with auto-rotation enabled.

## Credentials for the artifact registry

Obtain a JFrog access token from [repo.sodot.dev](https://repo.sodot.dev) (use the **Set Me Up** panel on the `sodot-terraform-modules` and `sodot-helm-charts` repos). The same username + token authenticates the Terraform module registry, the Helm OCI registry, and the in-cluster image pulls. The Sodot team whitelists your email domain for access.

## MPC shard identities and backup keys

Each Key Store and Policy Server node **self-generates its identity keypair on first boot** (persisted write-once in its database), and the Orchestrator propagates the cross-shard peer set during the setup ceremony. You therefore do **not** supply identity, signing, or verification keys. What you provide per shard is:

* **Names**: a name for each Key Store shard (e.g. `mpc-key-store-0`) and reader/writer names for each Policy Server.
* **A backup encryptor public key** per Key Store shard (32-byte / 64-hex). Key creation and import are blocked until every shard has one configured. Generate the backup keypair offline and keep the private half outside the cluster (see [Backup & DR](/deploy/operations/backup-dr)).

## SSO and authentication

* **Google OAuth client ID and client secret** for the hub cluster. The vault UI uses Google as the identity provider for human users. Setup Admin accounts must be Google Workspace accounts.
* **Setup Admin email addresses**: the list of Google accounts that will perform first-time passkey enrollment after deployment. Collect these before you run `helm install`.

## DNS, TLS, and OAuth

* A **DNS hostname** for the vault UI on your own domain (e.g. `vault.example.com`). It can be exposed internally (VPC/VPN only) or internet-facing.
* A **TLS certificate** covering that hostname. With the example Terraform, supply either an ISSUED **ACM certificate ARN in the hub cluster's region**, or a domain to look one up by (`ui_cert_domain`).
* **DNS**: either a public **Route53 hosted zone in the hub account** (the example creates the host's alias record for you), or manage DNS yourself and point it at the load balancer (the example outputs its DNS name via `ui_nlb_dns_name`).
* A **Google OAuth client** (client ID + secret) for UI login, with `https://<your-host>/auth/callback` registered as an authorized redirect URI. Setup Admins sign in with Google, so they must be Google Workspace accounts.

## CLI toolchain

| Tool | Minimum version |
|---|---|
| `kubectl` | 1.28 |
| `helm` | 3.12 |
| `aws` (AWS CLI) | 2.x |
| `terraform` | 1.14 (the example module and building blocks require `>= 1.14`; Sodot pins 1.15.x) |

## Multi-admin recommendation

If multiple people share the IT-admin role, plan to have at least two available during the verification ceremony after installation. The ceremony includes an out-of-band cross-check between operators that is easier to perform with two humans present.