Are There Boilerplates That Integrate Out-of-the-Box with AWS CDK?

Short answer: yes. But there’s a catch worth understanding before you pick one — most templates that advertise “AWS CDK support” ship little more than a starter config file, and that’s a very different thing from a boilerplate whose entire stack is defined in CDK and deploys with one command. Here’s how to tell them apart.

What “out-of-the-box CDK integration” should actually mean

The bar isn’t “there’s a cdk.json in the repo.” A boilerplate that genuinely integrates with AWS CDK should give you all of this on day one:

• The whole topology defined in CDK — DNS, certificates, auth, database, API, and every frontend, not just one Lambda as a demo.
• One-command deploy — a single cdk deploy brings the stacks up in dependency order, and tears them down just as cleanly.
• Separate stacks per concern — so the blast radius of a change is bounded and you can reason about each piece independently.
• Typed cross-stack references — a Cognito pool ID or API URL passed to a frontend as a checked value, not a string you copy by hand.
• App code and infra in one repo and one language — TypeScript end to end, so a change that spans your app and its infrastructure is a single, coherent edit.

Why most “CDK boilerplates” fall short

Search around and you’ll find three common disappointments. Some templates are app-only — a polished frontend or API with deployment left as “your problem,” CDK or otherwise. Some use a different IaC tool entirely (Serverless Framework, SAM, or Terraform) and mention CDK only in passing. And some include CDK but only for a single resource — one function, one bucket — leaving the auth, database, and frontend wiring for you to invent. In each case you still have to build the hard part: the integrated, multi-stack infrastructure that makes the app real.

What a real one looks like

cdkbase is built CDK-first by design. The entire application is expressed as a topology of nine CDK stacks — DNS, auth, database, API, billing, two MCP servers, and the web SPA and SSR frontends — wired together with typed references and deployed with one command:

pnpm run deploy   # builds the frontends, then cdk deploy --all

There’s no separate infrastructure project to reconcile and no hand-copied ARNs: the same TypeScript that builds your app defines the cloud it runs on. Add a feature and its stack in the same language; remove one by deleting its stack file and folder. Because it’s CDK on CloudFormation, every deploy also leaves an auditable record of exactly what was created — a property an API-driven tool doesn’t give you.

A checklist for evaluating any CDK boilerplate

Before you commit to one, ask:

• Does cdk deploy stand up the entire app, or just a sample?
• Are auth, database, and frontends all defined as CDK stacks?
• Are values passed between stacks as typed references, not manual config?
• Is there one repo and one language, or an app here and infra somewhere else?
• Can you deploy multiple environments (dev/prod) from the same code?

If the answer to those is yes, the CDK integration is real — not a checkbox.

The bottom line

So: yes, boilerplates that integrate out-of-the-box with AWS CDK exist — just hold them to the standard of “the whole stack deploys with one command,” not “there’s a CDK file in the repo.” That higher bar is exactly what cdkbase is, and it pairs the CDK foundation with auth, billing, a database, and frontends already wired in. See how the stack fits together or the getting-started guide.