CDK Deploy into Your AWS Account
The OpenBox team deploys the full stack into your AWS account using our CDK app: an EKS Auto Mode cluster, the OpenBox Helm release, DNS records, and a TLS certificate. You keep ownership of the account, the network, and the data; we drive the deployment.
Unlike the Helm chart path (you already run a cluster), the CDK path provisions the cluster too, and splits responsibility down a hard line:
| You (client) provide | We (operator) do |
|---|---|
| AWS account + admin deploy role | Run cdk deploy (3 stacks) |
| VPC, subnets, security group — we never create networking | Create the EKS Auto Mode cluster + node pools |
| Route53 public hosted zone + delegated domain | Install the OpenBox chart, create 5 DNS records + ACM wildcard cert |
| Service quotas (CPU + GPU) | Seed in-cluster credentials, wire secrets from your Secrets Manager |
| Secrets Manager entries (registry token for the GHCR chart, env files) | Verify convergence and hand over URLs |
GHCR or AWS Marketplace chart
The CDK app installs either build of the OpenBox chart, chosen by one config field, chartSource:
ghcr (default) | marketplace | |
|---|---|---|
| Chart and images | OpenBox release on GitHub Container Registry | AWS Marketplace build, served from the AWS Marketplace registry |
| Image access | Registry token in your Secrets Manager | Your account subscribes to the listing; nodes pull with their own IAM role — no token |
| Organization | Created only if you give an admin email | Always created — admin email required |
| PoC profile | Available | Not available |
We deliver a bundle built for one source; its example config already sets the matching chartSource, and the deployment refuses a config that names the other one.
When to pick this path
- You want OpenBox inside your compliance boundary (your account, your VPC, your KMS) without building the deployment yourself
- Your security team requires that networking (VPC/subnets/SGs/NACLs) is provisioned by you, under your standards
- You can grant a scoped admin role for the deployment window
Architecture overview
Secret values flow only from your Secrets Manager into cluster Secrets at deploy time — never through config files or the CDK code. The NLB is internal by default; the dashed question of how users reach it is a prerequisite decision (see Common Pitfalls).
What gets created in your account
- 3 CloudFormation stacks:
Openbox-Preflight,Openbox-Eks,Openbox-Workloads - EKS Auto Mode cluster (Kubernetes 1.31–1.36) with tainted node pools per workload line (cpu / memory / database / llm-GPU / guardrails)
- Internal NLB (default) fronting ingress-nginx, ACM wildcard certificate, 5 Route53 records under your domain
- The OpenBox Helm release: backend, core (+4 worker deployments), frontend, Keycloak, OPA, Temporal, Postgres, Redis, guardrails services, LlamaFirewall (vLLM on one GPU node), and the voice-agent executor (opt-in, disabled by default)
Before we schedule the deployment
Work through Client Prerequisites and fill every field of the config contract in Config Reference. Deployment does not start until every checklist item is confirmed — the CDK app validates the config and refuses to synthesize on missing or malformed values, so surprises surface in minutes, not mid-install.
Estimated time
- Client prerequisite work: 0.5–2 days (mostly waiting on quota increases and DNS delegation)
- Deployment window: ~60–90 minutes (EKS cluster ~20 min, workloads ~25 min, convergence checks the rest)