@go-to-k/cdkd 0.80.0 → 0.82.0

package/README.md

@@ -4,6 +4,7 @@
 
 - **Drop-in CDK compatible** — your existing CDK app code runs as-is.
 - **Up to 15x faster deploys than the AWS CDK CLI (CloudFormation)**
+- **Run AWS resources locally without deploying** — invoke Lambdas, serve API Gateway routes, and run ECS task definitions against Docker. SAM-compatible mental model, no `template.yaml` round-trip.
 
 ![cdkd demo](https://github.com/user-attachments/assets/0128730d-186d-4bd3-abea-aabc80ba4dd5)
 
@@ -23,6 +24,7 @@
 - **Rollback on failure**: When a deploy errors mid-stack, cdkd rolls back the resources it just created so the stack state stays consistent (CloudFormation parity — but cdkd does this without round-tripping through CFn). Pass `cdkd deploy --no-rollback` to skip rollback and keep the partial state for Terraform-style inspection / repair. See [Rollback behavior](#rollback-behavior).
 - **`--no-wait` for async resources**: Skip the multi-minute wait on CloudFront / RDS / ElastiCache / NAT Gateway and return as soon as the create call returns (CloudFormation always blocks)
 - **VPC route DependsOn relaxation (on by default)**: Drop CDK-injected defensive `DependsOn` edges from VPC Lambdas onto private-subnet routes so `CloudFront::Distribution` and `Lambda::Url` start their ~3-min propagation in parallel with NAT Gateway stabilization (~50% faster on VPC + Lambda + CloudFront stacks). Pass `--no-aggressive-vpc-parallel` to opt out.
+- **Local execution without deploying** (`cdkd local invoke` / `cdkd local start-api` / `cdkd local run-task`): run any Lambda — stand up every API Gateway route as a local HTTP server — or start every container in an `AWS::ECS::TaskDefinition` on a per-task docker network with the AWS-published metadata-endpoints sidecar. SAM-compatible mental model but reuses cdkd's synthesis / asset / route-discovery (no `template.yaml` round-trip). All AWS Lambda runtimes (Node.js / Python / Ruby / Java / .NET / `provided.*`) and one server per discovered API (HTTP API v2 / REST v1 / Function URL) with their own port / authorizers / CORS configs. `local run-task` is Phase 1 (single task, DependsOn ordering, IAM task-role via AssumeRole) — ECS Services / ALB routing / Service Connect are Phase 2 / Phase 3 follow-ups.
 
 > **Note**: Resource types not covered by either SDK Providers or Cloud Control API cannot be deployed with cdkd. If you encounter an unsupported resource type, deployment will fail with a clear error message.
 
@@ -584,12 +586,16 @@ containers `cdkd local invoke` uses. Modeled on `sam local start-api`
 but reusing cdkd's synthesis / route-discovery plumbing.
 
 ```bash
-# Auto-allocate a port (printed at startup) and serve every discovered route
+# Auto-allocate one port PER discovered API (printed at startup)
 cdkd local start-api
 
-# Pin to port 3000 (SAM-parity / curl muscle memory)
+# Pin the FIRST server to port 3000; subsequent APIs get 3001, 3002, ...
 cdkd local start-api --port 3000
 
+# Restrict to a single API by its CDK logical id (HTTP API / REST API logical
+# id, or the backing Lambda's logical id for Function URLs)
+cdkd local start-api --api MyAdminApi
+
 # Pre-warm one container per Lambda at server boot — eliminates first-request cold start
 cdkd local start-api --warm
 
@@ -606,6 +612,13 @@ cdkd local start-api --watch
 cdkd local start-api --stage prod
 ```
 
+**One server per API** (since v0.81): every discovered API surface gets its
+own HTTP server on its own port, so authorizers, CORS configs, and stage
+variables stay scoped to the owning API and never bleed across APIs that
+happen to share a path. `cdkd local start-api` prints one
+`Server listening on http://<host>:<port>  (<API> (<kind>))` line per
+server at startup; pass `--api <id>` to launch only one of them.
+
 Scope: REST v1 + HTTP API + Function URL with AWS_PROXY integrations.
 Authorizers (Lambda TOKEN/REQUEST + Cognito User Pool + HTTP v2 JWT),
 VPC-config Lambda warnings, CORS preflight, hot reload, and stage