I Built cdkd: Deploy Your Existing AWS CDK Code Up to 15x Faster

I built an OSS CLI tool called cdkd (CDK Direct) that speeds up deployments by up to 15x without changing a single line of your existing AWS CDK code.

You can use it just by replacing cdk deploy with cdkd deploy. What makes it special is that it achieves this speedup by deploying directly through the AWS SDK, without going through CloudFormation. On top of that, it can also run Lambda / API Gateway / ECS / CloudFront / Bedrock AgentCore and more locally.

And CloudFormation isn't the only thing it beats on speed. In a head-to-head benchmark against Terraform—which, like cdkd, provisions directly through the AWS SDK—cdkd came out faster on most test cases (more on this below).

go-to-k/cdkd

There is also a documentation site.

What is cdkd?

cdkd is a tool that rebuilds the AWS CDK CLI completely from scratch. Just by replacing cdk deploy with cdkd deploy, you can use it without changing any of your existing CDK app code at all.

There are three main features.

The GIF below shows the same CDK app actually deployed to AWS with cdkd deploy and cdk deploy, side by side. By the time cdkd finishes, CDK is still in the middle of creating the CloudFormation ChangeSet.

An Express mode that speeds up CloudFormation itself has also been announced, but even so, cdkd is about 2x faster, and nearly 9x faster for stacks that include asynchronous resources (see the benchmarks later for details).

AWS CloudFormation and CDK now support faster deployments (What's New)

That said, cdkd is not meant to replace the AWS CDK CLI, but rather to complement it. The idea is to use each where it shines: cdkd for fast iteration during development and testing, and the AWS CDK CLI for production deployments where you want to leverage the strengths of CloudFormation. The two can be migrated bidirectionally with cdkd import / cdkd export, so you can freely move back and forth later (more on this below).

It also pairs well with AI-driven development. cdkd isn't just fast at deploying—cdkd destroy is fast too, since it deletes directly through the AWS SDK without going through CloudFormation, so you can keep each build-and-tear-down cycle short.

Why I built it

CDK's slow deployments quietly add up during development and testing. Because CDK internally goes through CloudFormation, every change carries the overhead of CFn.

The CDK CLI does have a fast mode, cdk deploy --hotswap, which updates things like Lambda code directly without going through CloudFormation. However, it causes drift between the CloudFormation stack state and the actual environment.

So cdkd was born to speed up deployments by calling the AWS SDK directly instead of going through CloudFormation—while keeping your existing CDK app code as-is—and, as a bonus, to even provide local execution using CDK's synthesis output.

Feature 1: Up to 15x faster deployments

The biggest selling point of cdkd is right here: speed.

cdkd provisions resources by calling the AWS SDK directly, without going through CloudFormation. It reproduces what CloudFormation does from scratch, and adds its own optimizations on top, achieving blazing-fast deployments.

The main mechanisms are as follows.

• Hybrid provisioning: Major resources go through a fast, dedicated SDK Provider, while the rest fall back to the Cloud Control API to cover a wide range of resource types
• Parallel execution via a dependency graph (DAG): Analyzes the Ref / Fn::GetAtt dependencies within the template and deploys resources with no dependencies in parallel
• --no-wait: Skips the wait time for asynchronous resources like CloudFront / RDS / ElastiCache / NAT Gateway that "take several minutes to fully stabilize," moving on to the next step as soon as the Create call returns

Benchmarks

These measurements cover only the deploy phase, excluding synth time (since both cdkd and CDK go through the same aws-cdk-lib for synth).

In addition to normal CloudFormation (Normal), we also include the newly announced Express mode in the comparison. Express mode is a fast mode that skips waiting for resources to stabilize, with behavior close to cdkd's --no-wait.

(Fastest of three runs, in seconds, us-west-2)

The VPC + Lambda + SQS + CloudFront stack consists of a VPC (2 AZs, NAT Gateway, public/private subnets) + VPC Lambda + Lambda Function URL + CloudFront Distribution + SQS + EventSourceMapping + Consumer Lambda.

The "up to 15x" in the title comes from this VPC stack. Against Normal CFn's 562 seconds, cdkd --no-wait finishes in 40 seconds—over 14x faster (achieved by letting AWS handle CloudFront propagation and NAT Gateway stabilization in the background). Even the default without --no-wait is about 3x faster (197 seconds), by running CloudFront / Lambda URL / VPC Lambda concurrently with NAT Gateway propagation.

Even for a simple SQS stack, cdkd finishes in 9 seconds against Normal's 83 seconds—about 9x faster.

Compared to Express mode as well, cdkd comes out faster than Express on most stacks. It finishes about 1.5–2x faster than Express, and about 2.4x faster for SQS.

And if you combine --no-wait, then even for stacks that include asynchronous resources such as VPC—Express's strong suit—cdkd is about 9x faster than Express (Express 366 seconds → cdkd --no-wait 40 seconds).

One thing to note: cdkd tends to be faster for resources where the dedicated SDK Provider applies. For stacks that mostly consist of resources going through the Cloud Control API fallback (Athena WorkGroup, SSM Document, etc.), the speedup may land in the range of about 1.5–3x.

Speed comparison with Terraform

The benchmarks above were against CloudFormation, but I also compared speed against Terraform, which—like cdkd—provisions by calling AWS APIs directly through the AWS SDK. I expressed the same logical configuration in both AWS CDK and Terraform, and compared the median of 7 runs across 6 test cases.

(Median of 7 runs, in seconds; bold marks the faster of cdkd / Terraform)

The result: cdkd was fastest in 4 of the 6 test cases, coming out 1.23–2.31x faster than Terraform (the remaining two, webapp and cloudfront, were within measurement noise and are treated as ties).

The code I used for the benchmarks is available in the repository below.

go-to-k/cdkd-bench-terraform

Feature 2: Your existing CDK code runs as-is

cdkd has no IaC language or syntax of its own. Its approach is to use the CDK app code you're already writing, exactly as-is, without changing anything.

Mechanically, it reads --app from cdk.json, runs the CDK app as a subprocess, and parses the Cloud Assembly (= CloudFormation templates) that aws-cdk-lib generates. In other words, the synth part goes through exactly the same code as CDK. What cdkd builds on its own is the engine that comes after: how to deploy the template.

It supports the standard CloudFormation features: context provider loops such as Vpc.fromLookup() and SSM / HostedZone, uploading S3 file assets and Docker image (ECR) assets, intrinsic functions like Ref / Fn::GetAtt, cross-stack references, custom resources, and more.

# In your existing CDK app directory, just replace cdk with cdkd cdkd deploy cdkd diff cdkd destroy 

--app is read automatically from cdk.json, so in most cases you don't even need to specify the option.

Feature 3: Local execution of CDK apps

Using a CDK app's synth output, cdkd can also run Lambda / API Gateway / ECS and more on local Docker without deploying to AWS. It feels the same as sam local *, but you don't need to prepare a separate template.yaml or pipe things together with cdk synth | sam .... It reuses cdkd's own synth, asset, and route-resolution mechanisms directly.

# Run a Lambda one-off cdkd local invoke MyStack/Handler --event events/get.json # Serve API Gateway / HTTP API / Function URL routes on a local server cdkd local start-api # Launch an ECS task locally cdkd local run-task MyStack/MyService/TaskDef 

It supports all current Lambda runtimes, including Node.js / Python / Ruby / Java / .NET / provided.*. Adding --from-state lets you run locally with deployed environment variables and secrets resolved (values expressed by intrinsic functions like table.tableName are properly resolved to their actual values, even locally).

It works even on stacks operated with cdk deploy (CloudFormation)

The --from-state above is a mechanism for stacks deployed with cdkd, but you can do the same thing for stacks deployed with the AWS CDK CLI's cdk deploy (CloudFormation) using --from-cfn-stack.

# For a stack deployed with cdkd cdkd local invoke MyStack/Handler --from-state # For a stack operated with cdk deploy (CFn), you can run it locally the same way cdkd local invoke MyStack/Handler --from-cfn-stack 

Put another way, even if you didn't deploy with cdkd, you can run Lambda / API Gateway / ECS and more locally just by using cdkd local * against a stack you're already operating with cdk deploy. No migration to cdkd is required. I think this can also serve as an entry point for AWS CDK CLI users who feel, "I'm not ready to try cdkd's fast deployments yet, but I'd like to adopt just the local execution experience."

By the way, I'm also building cdk-local (cdkl) as a separate tool dedicated to local execution. It's positioned as a standalone spin-off of cdkd's local feature, and it additionally comes with a browser-based console, cdkl studio (where you can view invocations, responses, and container logs on a timeline). If you don't need cdkd's deployment features and purely want to adopt local execution, this one is more lightweight.

go-to-k/cdk-local

How cdkd works

The overall flow looks like this.

┌─────────────────┐ │ Your CDK App │ (aws-cdk-lib) └────────┬────────┘ │ ▼ ┌─────────────────┐ │ cdkd Synthesis │ Subprocess execution + Cloud Assembly parsing └────────┬────────┘ │ ▼ ┌─────────────────┐ │ CloudFormation │ │ Template │ └────────┬────────┘ │ ▼ ┌─────────────────┐ │ Asset Build & │ S3 ZIP upload / ECR image build and push │ Publish │ └────────┬────────┘ │ ▼ ┌─────────────────┐ │ cdkd Engine │ │ - DAG analysis │ Build the dependency graph │ - Diff calc │ Diff against existing resources │ - Parallel exec │ Dispatch immediately when pending deps hit 0 └────────┬────────┘ │ ┌────┴────┐ ▼ ▼ ┌────────┐ ┌────────┐ │ SDK │ │ Cloud │ │Provider│ │Control │ Covers many additional │ │ │ API │ types via fallback └────────┘ └────────┘ 

The key point is that the structure keeps everything up to synth exactly the same as CDK, and cdkd's own engine takes over from there. Asset build and publish, the diff calculation that compares the template against the current resource state, and the parallel execution driven by dependency analysis are all implemented in-house.

For state management, it uses S3 and acquires locks via S3 conditional writes (a cdkd-state-{accountId} bucket). If a deployment fails midway, like CloudFormation, it rolls back only the resources created in that run to keep state consistent (you can also leave the intermediate state behind by adding --no-rollback).

Migrating between CloudFormation and cdkd

You can migrate bidirectionally between cdkd and CloudFormation.

• cdkd import --migrate-from-cloudformation: Takes a stack that's already managed by CloudFormation via cdk deploy into cdkd management, without recreating resources
• cdkd export: Hands a cdkd-managed stack over to CloudFormation (it uses ChangeSetType=IMPORT, so AWS resources are not recreated)

You can switch whenever you feel like migrating.

Installation and usage

Prerequisites

• Node.js >= 22.12.0
• AWS credentials that can create the resources your stacks deploy. cdkd calls each service's API directly, so it needs the permissions you would need to create those resources by hand. It also needs a small set of permissions for the S3 bucket for state management and the place to store assets (S3, ECR).

Installation

npm i -g @go-to-k/cdkd 

Quick start

cdkd requires cdkd bootstrap only the first time, which creates an S3 bucket for state management and a place to store assets (you don't need cdk bootstrap—this one alone is enough).

# Create the S3 bucket for state management (once per AWS account) cdkd bootstrap # List the stacks in the CDK app cdkd list # Deploy cdkd deploy # Check the diff cdkd diff # Destroy cdkd destroy 

--app is auto-resolved from cdk.json, and the state bucket is auto-resolved from your AWS account ID, so basically this is all you need.

Skill for AI Coding Agents

The repository also ships a Skill for using cdkd safely.

With Claude Code, running the following in a session installs it as a plugin.

/plugin marketplace add go-to-k/cdkd /plugin install cdkd-skills@cdkd 

After that, the Skill kicks in automatically when you ask something like "deploy this CDK stack with cdkd," and you can also invoke it directly with /cdkd.

For agents that support the SKILL.md format, such as Codex and Cursor, you can install it with the GitHub CLI (v2.90 or later) or npx skills.

gh skill install go-to-k/cdkd cdkd # or npx skills add go-to-k/cdkd --skill cdkd 

Beyond usage—from installation to checking ahead with cdkd diff, deploying, verifying, and running locally—the Skill also spells out safety-side rules: use cdkd for development and testing rather than production, and never run cdkd deploy against a CloudFormation-managed stack implicitly.

Wrapping up

I built cdkd because I wanted to improve two experiences that are unglamorous but pay off every day—deployment speed during development and local execution—while keeping the "declarative goodness" of CDK intact. You can try it just by replacing cdk with cdkd, without changing a single line of your existing CDK code, so the barrier to entry should be low.

That said, cdkd is still in development and is not intended for production deployments. I'd be happy if you try it out in development and testing. I think it's easiest to see the value in situations like "deployments during development are painfully slow" or "I want to quickly run Lambda or ECS locally."

For detailed documentation (supported resource types, import / export procedures, the finer behaviors of local execution, and so on), please check the README on GitHub or the documentation site. If you like it, please give it a star!

go-to-k/cdkd

By the way, there's also a sister tool dedicated to local execution, cdk-local (cdkl). If you only want to adopt local execution, do check this one out too.

go-to-k/cdk-local

Also, cdkd was developed by delegating nearly all of the implementation to a Coding Agent. I've introduced markgate—a tool that mechanically supports that development—in a separate article, so please take a look if you're interested.

go-to-k/markgate