# Resource setup examples

Enrollment adopts an existing machine. Terraform is optional infrastructure
preparation when you need to create resources first; it neither enrolls nymph nor
implements the planned host API. The examples below live in the CLI implementation
branch and must be adapted to your AWS account before any real infrastructure
plan or apply. No cloud resources were created by the documentation checks.

| Starting resource | Example or adoption path |
| --- | --- |
| Existing workstation or server | Verify SSH access, then follow [Enroll a host](/lakeshore/hosts/enroll.md); no Terraform required. |
| New AWS SSH machine | `examples/terraform/aws-ssh-host/` creates one EC2 host in an existing subnet using an existing EC2 key pair and restricted SSH source CIDRs. |
| Existing bos14 cluster | Adopt `fortyfive/bos14/bos14-ctrl` using your existing Unix/SSH access; configure its Slurm runner separately. Do not provision a replacement Slurm cluster. |
| New AWS Kubernetes cluster | `examples/terraform/aws-eks/` wraps the existing kube-provider Terraform template; review private endpoint access, node pools, and costs. |

## Prepare an AWS example

From the CLI repository checkout, copy the example variables and replace every
account-specific placeholder:

```shell
cd examples/terraform/aws-ssh-host
cp terraform.tfvars.example terraform.tfvars
terraform init -backend=false
terraform validate
terraform test
```

Use `examples/terraform/aws-eks` for the EKS example with the same preparation
steps. The test suites use mocked providers and do not prove AWS credentials,
quotas, permissions, routes, or actual provisioning. Only run a real Terraform
plan after choosing the region, existing network/key resources, access boundaries,
and intended capacity. Applying infrastructure is separate from these checks.

For an SSH host, `public_ip = false` requires private network or bastion access;
setting it true still requires a subnet with a suitable route. The example uses
an existing EC2 key-pair name; it does not upload your private key or store
credentials in the DreamLake vault. Choose the AMI's corresponding SSH user and
configure your local alias after provisioning, then use the enrollment guide.

For EKS, the API endpoint and workload nodes are separate from the host running
nymph. A submission host must already be able to reach and authenticate to the
cluster API. Provisioning EKS does not create a verified Kubernetes runner,
configure code/data staging, or establish a nymph connection. Existing EC2/k3s
infrastructure is a different setup and must not be treated as EKS.

## Related documentation

- **[Terraform example collection](https://github.com/dreamlake-ai/dreamlake-cli/tree/feat/218-host-enrollment/examples/terraform)** — Account-adaptable resource examples and their offline validation instructions.
- **[AWS SSH host example](https://github.com/dreamlake-ai/dreamlake-cli/tree/feat/218-host-enrollment/examples/terraform/aws-ssh-host)** — A single SSH-accessible EC2 resource with explicit network and key-pair inputs.
- **[AWS EKS example](https://github.com/dreamlake-ai/dreamlake-cli/tree/feat/218-host-enrollment/examples/terraform/aws-eks)** — Example values and tests using the existing kube template as the infrastructure source.
- **[Existing EC2 provider template](https://github.com/dreamlake-ai/dreamlake-cli/tree/feat/218-host-enrollment/src/cli/provider/templates/ec2)** — A separate SSM-managed head/worker cluster; its private head is not the single-SSH-host example.
- **[Enroll a host](/lakeshore/hosts/enroll.md)** — Host naming, bootstrap, consent, and readiness after infrastructure is available.
- **[Python API requirements](/dev/plans/hosts-python-api)** — SDK documentation and example-test requirements; resource provisioning remains a separate API scope.