@go-to-k/cdkd 0.267.15 → 0.267.17
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +67 -93
- package/dist/{asg-provider-BhY47O9R.js → asg-provider-CGSEz9er.js} +2 -2
- package/dist/{asg-provider-BhY47O9R.js.map → asg-provider-CGSEz9er.js.map} +1 -1
- package/dist/cli.js +139 -8
- package/dist/cli.js.map +1 -1
- package/dist/{deploy-engine-D7oQWXsX.js → deploy-engine-D-55wJlE.js} +3 -3
- package/dist/{deploy-engine-D7oQWXsX.js.map → deploy-engine-D-55wJlE.js.map} +1 -1
- package/dist/index.js +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -6,8 +6,9 @@
|
|
|
6
6
|
|
|
7
7
|
Drop-in CDK CLI for existing CDK apps — up to 15x faster deploys via direct AWS SDK calls instead of CloudFormation.
|
|
8
8
|
|
|
9
|
-
- **Drop-in CDK compatible**: your existing CDK app code runs as-is
|
|
9
|
+
- **Drop-in CDK compatible**: your existing CDK app code runs as-is; just replace `cdk deploy` with `cdkd deploy`.
|
|
10
10
|
- **Up to 15x faster deploys**: direct SDK calls, aggressive parallelization, and `--no-wait` to skip slow stabilization waits.
|
|
11
|
+
- **Faster than Terraform and CloudFormation Express mode**: wins or ties every benchmarked scenario against Terraform, and beats CloudFormation's own fast-deploy option on nearly every stack, by up to 9x (see [Benchmark](#benchmark)).
|
|
11
12
|
|
|
12
13
|
|
|
13
14
|
|
|
@@ -20,11 +21,11 @@ Drop-in CDK CLI for existing CDK apps — up to 15x faster deploys via direct AW
|
|
|
20
21
|
|
|
21
22
|
## Benchmark
|
|
22
23
|
|
|
23
|
-
**cdkd deploys up to 15x faster than AWS CDK (CloudFormation)** on SDK-Provider-handled stacks; the per-stack speedup widens with size and parallelism
|
|
24
|
+
**cdkd deploys up to 15x faster than AWS CDK (CloudFormation)** on SDK-Provider-handled stacks; the per-stack speedup widens with size and parallelism.
|
|
24
25
|
|
|
25
26
|
Numbers below are deploy-phase only (CDK app synthesis is identical between cdkd and AWS CDK — both run the same user code through `aws-cdk-lib`'s synthesizer — so synth time is excluded from the speedup calculation).
|
|
26
27
|
|
|
27
|
-
### vs CloudFormation Express mode
|
|
28
|
+
### vs CloudFormation Express mode: up to 9x faster
|
|
28
29
|
|
|
29
30
|
CloudFormation's [Express mode](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-cloudformation-cdk/) is a fast-deploy option that skips resource stabilization waits, similar in spirit to cdkd's `--no-wait`. Even so, cdkd is faster than Express on nearly every stack, and with `--no-wait` it pulls dramatically ahead on stacks dominated by async resources.
|
|
30
31
|
|
|
@@ -45,49 +46,84 @@ Best of 3 runs, deploy-phase only, seconds, `us-west-2`. The `VPC + Lambda + SQS
|
|
|
45
46
|
- **Async-heavy stacks are where the gap explodes.** On the VPC + CloudFront stack, `cdkd --no-wait` finishes in 40s vs Express's 366s (~9x) — cdkd returns as soon as each create call returns, leaving CloudFront propagation and NAT Gateway stabilization to complete in the background.
|
|
46
47
|
- **S3 is the one case where Express edges cdkd's default** (22s vs 23s). On a near-instant single-resource stack there is little left to parallelize, and `--no-wait` makes no difference there.
|
|
47
48
|
|
|
48
|
-
###
|
|
49
|
+
### vs Terraform: cdkd wins or ties every scenario
|
|
49
50
|
|
|
50
|
-
|
|
51
|
+
We also raced cdkd against Terraform: the same logical stacks expressed both as CDK apps and as Terraform HCL, deployed by all engines against real AWS.
|
|
51
52
|
|
|
52
|
-
| |
|
|
53
|
-
| --- | ---: | ---: | ---: |
|
|
54
|
-
|
|
|
53
|
+
| Scenario | Stack | cdkd | cdkd `--no-wait` | Terraform | CloudFormation |
|
|
54
|
+
| --- | --- | ---: | ---: | ---: | ---: |
|
|
55
|
+
| wide | 48 independent resources (S3 / DynamoDB / SQS / SNS / SSM / Logs, 8 each) | **25.4** | 25.3 | 50.4 | 85.9 |
|
|
56
|
+
| serverless | Lambda ×3 + HTTP API + DynamoDB + SNS / SQS + EventBridge | **31.4** | 31.8 | 57.9 | 124.2 |
|
|
57
|
+
| webapp | VPC + NAT + subnets + DynamoDB + SQS + S3 + Lambda ×2 + HTTP API | 127.0 | **32.4** | 127.8 | 161.9 |
|
|
58
|
+
| cloudfront | S3 origin + CloudFront + OAC | **171.2** | **17.8** | 191.1 | 208.1 |
|
|
55
59
|
|
|
56
|
-
|
|
60
|
+
Cold end-to-end wall clock (unlike the deploy-phase-only tables above, these numbers include synth / plan), median of 3 runs, seconds, `us-east-1`. On wide, parallel stacks cdkd is ~2x faster than Terraform; where a single slow resource dominates (NAT Gateway, CloudFront propagation), physical provisioning time sets a common floor and only `--no-wait` gets below it. Full methodology, parity notes, and reproduction scripts live in [cdkd-bench-terraform](https://github.com/go-to-k/cdkd-bench-terraform).
|
|
57
61
|
|
|
58
|
-
|
|
62
|
+
### More benchmarks
|
|
59
63
|
|
|
60
|
-
|
|
61
|
-
| --- | ---: | ---: | ---: |
|
|
62
|
-
| Deploy | **599s** | 197s (3.0x) | **40s (15.0x)** |
|
|
64
|
+
The full benchmark suite lives in [docs/benchmarks.md](docs/benchmarks.md): the SDK Provider path (**5.5x**, 17.0s vs 94.4s), the VPC + CloudFront + Lambda stack behind the headline **15x** (40s vs 599s with `--no-wait`), the Cloud Control API fallback path (**1.6x**), and the Terraform comparison in full detail. Reproduction scripts: [tests/benchmark](tests/benchmark/README.md).
|
|
63
65
|
|
|
64
|
-
|
|
66
|
+
## Prerequisites
|
|
65
67
|
|
|
66
|
-
|
|
68
|
+
- **Node.js** >= 20.0.0
|
|
69
|
+
- **AWS credentials with admin-equivalent permissions** for the resources being deployed. cdkd does NOT route through CloudFormation, so CDK CLI's `cdk-hnb659fds-deploy-role-*` is NOT sufficient — see [`--role-arn`](docs/cli-reference.md).
|
|
67
70
|
|
|
68
|
-
|
|
71
|
+
AWS CDK's `cdk bootstrap` is not required. Instead, run `cdkd bootstrap` once per
|
|
72
|
+
account: it creates everything cdkd needs, and per-region asset storage is added
|
|
73
|
+
automatically on the first `cdkd deploy` into each region. Existing setups,
|
|
74
|
+
legacy-mode opt-outs, and how this relates to `cdk bootstrap`: see
|
|
75
|
+
[Upgrading from an earlier cdkd version](#upgrading-from-an-earlier-cdkd-version).
|
|
69
76
|
|
|
70
|
-
|
|
71
|
-
| --- | ---: | ---: | ---: |
|
|
72
|
-
| Deploy | **64.9s** | **40.9s** | **1.6x** |
|
|
77
|
+
## Installation
|
|
73
78
|
|
|
74
|
-
|
|
79
|
+
```bash
|
|
80
|
+
npm i -g @go-to-k/cdkd # latest release
|
|
81
|
+
npm i -g @go-to-k/cdkd@0.0.2 # pin to a specific version
|
|
82
|
+
```
|
|
75
83
|
|
|
76
|
-
|
|
84
|
+
The installed binary is `cdkd`.
|
|
77
85
|
|
|
78
|
-
|
|
86
|
+
## Quick Start
|
|
79
87
|
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
88
|
+
> **First-time setup**: cdkd requires a one-time `cdkd bootstrap` per AWS
|
|
89
|
+
> account before any other command will work — it creates the S3 state
|
|
90
|
+
> bucket (`cdkd-state-{accountId}`) that cdkd uses to track deployed
|
|
91
|
+
> resources, plus cdkd-owned asset storage for the region
|
|
92
|
+
> (by default a `cdkd-assets-{accountId}-{region}` bucket +
|
|
93
|
+
> `cdkd-container-assets-{accountId}-{region}` ECR repo — custom names via
|
|
94
|
+
> `--asset-bucket` / `--container-repo`, skip with `--no-assets`; see
|
|
95
|
+
> [`cdkd bootstrap`](docs/cli-reference.md#cdkd-bootstrap)).
|
|
96
|
+
> This replaces `cdk bootstrap`, which cdkd does not require — see
|
|
97
|
+
> [Prerequisites](#prerequisites).
|
|
98
|
+
|
|
99
|
+
```bash
|
|
100
|
+
# Bootstrap (creates S3 state bucket + asset storage — one-time setup per AWS account)
|
|
101
|
+
cdkd bootstrap
|
|
86
102
|
|
|
87
|
-
|
|
103
|
+
# List stacks in the CDK app
|
|
104
|
+
cdkd list
|
|
105
|
+
|
|
106
|
+
# Deploy your CDK app
|
|
107
|
+
cdkd deploy
|
|
108
|
+
|
|
109
|
+
# Check what would change
|
|
110
|
+
cdkd diff
|
|
88
111
|
|
|
89
|
-
|
|
90
|
-
|
|
112
|
+
# Tear down
|
|
113
|
+
cdkd destroy
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
That's it. cdkd reads `--app` from `cdk.json` and auto-resolves the state bucket from your AWS account ID (`cdkd-state-{accountId}`). If you bootstrapped under a previous cdkd version, the legacy region-suffixed name (`cdkd-state-{accountId}-{region}`) is still picked up automatically with a deprecation warning.
|
|
117
|
+
|
|
118
|
+
### Upgrading from an earlier cdkd version
|
|
119
|
+
|
|
120
|
+
**No breaking change, no manual step: just deploy.** The first `cdkd deploy` into
|
|
121
|
+
each region auto-creates the cdkd-owned asset storage (interactive runs are asked
|
|
122
|
+
once per region, `--yes` / CI runs create it automatically) and shows a one-time
|
|
123
|
+
in-place UPDATE repointing asset references — content identical, no replacement.
|
|
124
|
+
Downgrading is safe too (older binaries ignore the marker). Explicit pre-provisioning
|
|
125
|
+
(`cdkd bootstrap --region <r>`), legacy-mode opt-outs, and how this relates to
|
|
126
|
+
`cdk bootstrap`: see [`cdkd bootstrap`](docs/cli-reference.md#cdkd-bootstrap).
|
|
91
127
|
|
|
92
128
|
## Features
|
|
93
129
|
|
|
@@ -151,68 +187,6 @@ For a step-by-step walkthrough of the full `cdkd deploy` pipeline (CLI
|
|
|
151
187
|
parsing → synthesis → asset publishing → per-stack deploy), see
|
|
152
188
|
[docs/architecture.md](docs/architecture.md#5-end-to-end-pipeline-walkthrough-cdkd-deploy).
|
|
153
189
|
|
|
154
|
-
## Prerequisites
|
|
155
|
-
|
|
156
|
-
- **Node.js** >= 20.0.0
|
|
157
|
-
- **AWS credentials with admin-equivalent permissions** for the resources being deployed. cdkd does NOT route through CloudFormation, so CDK CLI's `cdk-hnb659fds-deploy-role-*` is NOT sufficient — see [`--role-arn`](docs/cli-reference.md).
|
|
158
|
-
|
|
159
|
-
AWS CDK's `cdk bootstrap` is not required. Instead, run `cdkd bootstrap` once per
|
|
160
|
-
account: it creates everything cdkd needs, and per-region asset storage is added
|
|
161
|
-
automatically on the first `cdkd deploy` into each region. Existing setups,
|
|
162
|
-
legacy-mode opt-outs, and how this relates to `cdk bootstrap`: see
|
|
163
|
-
[Upgrading from an earlier cdkd version](#upgrading-from-an-earlier-cdkd-version).
|
|
164
|
-
|
|
165
|
-
## Installation
|
|
166
|
-
|
|
167
|
-
```bash
|
|
168
|
-
npm i -g @go-to-k/cdkd # latest release
|
|
169
|
-
npm i -g @go-to-k/cdkd@0.0.2 # pin to a specific version
|
|
170
|
-
```
|
|
171
|
-
|
|
172
|
-
The installed binary is `cdkd`.
|
|
173
|
-
|
|
174
|
-
## Quick Start
|
|
175
|
-
|
|
176
|
-
> **First-time setup**: cdkd requires a one-time `cdkd bootstrap` per AWS
|
|
177
|
-
> account before any other command will work — it creates the S3 state
|
|
178
|
-
> bucket (`cdkd-state-{accountId}`) that cdkd uses to track deployed
|
|
179
|
-
> resources, plus cdkd-owned asset storage for the region
|
|
180
|
-
> (by default a `cdkd-assets-{accountId}-{region}` bucket +
|
|
181
|
-
> `cdkd-container-assets-{accountId}-{region}` ECR repo — custom names via
|
|
182
|
-
> `--asset-bucket` / `--container-repo`, skip with `--no-assets`; see
|
|
183
|
-
> [`cdkd bootstrap`](docs/cli-reference.md#cdkd-bootstrap)).
|
|
184
|
-
> This replaces `cdk bootstrap`, which cdkd does not require — see
|
|
185
|
-
> [Prerequisites](#prerequisites).
|
|
186
|
-
|
|
187
|
-
```bash
|
|
188
|
-
# Bootstrap (creates S3 state bucket + asset storage — one-time setup per AWS account)
|
|
189
|
-
cdkd bootstrap
|
|
190
|
-
|
|
191
|
-
# List stacks in the CDK app
|
|
192
|
-
cdkd list
|
|
193
|
-
|
|
194
|
-
# Deploy your CDK app
|
|
195
|
-
cdkd deploy
|
|
196
|
-
|
|
197
|
-
# Check what would change
|
|
198
|
-
cdkd diff
|
|
199
|
-
|
|
200
|
-
# Tear down
|
|
201
|
-
cdkd destroy
|
|
202
|
-
```
|
|
203
|
-
|
|
204
|
-
That's it. cdkd reads `--app` from `cdk.json` and auto-resolves the state bucket from your AWS account ID (`cdkd-state-{accountId}`). If you bootstrapped under a previous cdkd version, the legacy region-suffixed name (`cdkd-state-{accountId}-{region}`) is still picked up automatically with a deprecation warning.
|
|
205
|
-
|
|
206
|
-
### Upgrading from an earlier cdkd version
|
|
207
|
-
|
|
208
|
-
**No breaking change, no manual step: just deploy.** The first `cdkd deploy` into
|
|
209
|
-
each region auto-creates the cdkd-owned asset storage (interactive runs are asked
|
|
210
|
-
once per region, `--yes` / CI runs create it automatically) and shows a one-time
|
|
211
|
-
in-place UPDATE repointing asset references — content identical, no replacement.
|
|
212
|
-
Downgrading is safe too (older binaries ignore the marker). Explicit pre-provisioning
|
|
213
|
-
(`cdkd bootstrap --region <r>`), legacy-mode opt-outs, and how this relates to
|
|
214
|
-
`cdk bootstrap`: see [`cdkd bootstrap`](docs/cli-reference.md#cdkd-bootstrap).
|
|
215
|
-
|
|
216
190
|
## Usage
|
|
217
191
|
|
|
218
192
|
cdkd has three command families:
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
import { E as clearOnUpdateRemoval, L as normalizeAwsTagsToCfn, fn as __exportAll, j as disableInstanceApiTermination, rn as ResourceUpdateNotSupportedError, tn as ProvisioningError, z as assertRegionMatch } from "./deploy-engine-
|
|
1
|
+
import { E as clearOnUpdateRemoval, L as normalizeAwsTagsToCfn, fn as __exportAll, j as disableInstanceApiTermination, rn as ResourceUpdateNotSupportedError, tn as ProvisioningError, z as assertRegionMatch } from "./deploy-engine-D-55wJlE.js";
|
|
2
2
|
import { n as getLogger, u as generateResourceName } from "./logger-BYMEE-BS.js";
|
|
3
3
|
import { EC2Client } from "@aws-sdk/client-ec2";
|
|
4
4
|
import { AttachLoadBalancerTargetGroupsCommand, AttachLoadBalancersCommand, AttachTrafficSourcesCommand, AutoScalingClient, CreateAutoScalingGroupCommand, CreateOrUpdateTagsCommand, DeleteAutoScalingGroupCommand, DeleteLifecycleHookCommand, DeleteNotificationConfigurationCommand, DeleteTagsCommand as DeleteTagsCommand$1, DescribeAutoScalingGroupsCommand, DescribeLifecycleHooksCommand, DescribeNotificationConfigurationsCommand, DescribeTrafficSourcesCommand, DetachLoadBalancerTargetGroupsCommand, DetachLoadBalancersCommand, DetachTrafficSourcesCommand, DisableMetricsCollectionCommand, EnableMetricsCollectionCommand, PutLifecycleHookCommand, PutNotificationConfigurationCommand, UpdateAutoScalingGroupCommand } from "@aws-sdk/client-auto-scaling";
|
|
@@ -810,4 +810,4 @@ function mapNotificationsToCfn(configurations) {
|
|
|
810
810
|
|
|
811
811
|
//#endregion
|
|
812
812
|
export { asg_provider_exports as n, ASGProvider as t };
|
|
813
|
-
//# sourceMappingURL=asg-provider-
|
|
813
|
+
//# sourceMappingURL=asg-provider-CGSEz9er.js.map
|