This is the AWS CDK v2 Developer Guide. The older CDK v1 entered maintenance on June 1, 2022 and ended support on June 1, 2023.
cdk deploy
Deploy one or more AWS CDK stacks into your AWS environment.
During deployment, the CDK CLI will output progress indicators, similar to what can be observed from the AWS CloudFormation console.
If the AWS environment is not bootstrapped, only stacks without assets and with synthesized templates under 51,200 bytes will successfully deploy.
Usage
$
cdk deploy
<arguments>
<options>
Arguments
- CDK stack ID
-
The construct ID of the CDK stack from your app to deploy.
Type: String
Required: No
Options
For a list of global options that work with all CDK CLI commands, see Global options.
--all
BOOLEAN
-
Deploy all stacks in your CDK app.
Default value:
false
--asset-parallelism
BOOLEAN
-
Specify whether to build and publish assets in parallel.
--asset-prebuild
BOOLEAN
-
Specify whether to build all assets before deploying the first stack. This option is useful for failing Docker builds.
Default value:
true
--build-exclude, -E
ARRAY
-
Do not rebuild asset with the given ID.
This option can be specified multiple times in a single command.
Default value:
[]
--change-set-name
STRING
-
The name of the AWS CloudFormation change set to create.
This option is not compatible with
--method='direct'
. --concurrency
NUMBER
-
Deploy multiple stacks in parallel while accounting for inter-stack dependencies. Use this option to speed up deployments. You must still factor in AWS CloudFormation and other AWS account rate limiting.
Provide a number to specify the maximum number of simultaneous deployments (dependency permitting) to perform.
Default value:
1
--exclusively, -e
BOOLEAN
-
Only deploy requested stacks and don't include dependencies.
--force, -f
BOOLEAN
-
When you deploy to update an existing stack, the CDK CLI will compare the template and tags of the deployed stack to the stack about to be deployed. If no changes are detected, the CDK CLI will skip deployment.
To override this behavior and always deploy stacks, even if no changes are detected, use this option.
Default value:
false
--help, -h
BOOLEAN
-
Show command reference information for the
cdk deploy
command. --hotswap
BOOLEAN
-
Hotswap deployments for faster development. This option attempts to perform a faster, hotswap deployment if possible. For example, if you modify the code of a Lambda function in your CDK app, the CDK CLI will update the resource directly through service APIs instead of performing a CloudFormation deployment.
If the CDK CLI detects changes that don’t support hotswapping, those changes will be ignored and a message will display. If you prefer to perform a full CloudFormation deployment as a fall back, use
--hotswap-fallback
instead.The CDK CLI uses your current AWS credentials to perform the API calls. It does not assume the roles from your bootstrap stack, even if the
@aws-cdk/core:newStyleStackSynthesis
feature flag is set totrue
. Those roles do not have the necessary permissions to update AWS resources directly, without using CloudFormation. For that reason, make sure that your credentials are for the same AWS account of the stacks that you are performing hotswap deployments against and that they have the necessary IAM permissions to update the resources.Hotswapping is currently supported for the following changes:
-
Code assets (including Docker images and inline code), tag changes, and configuration changes (only description and environment variables are supported) of Lambda functions.
-
Lambda versions and alias changes.
-
Definition changes of AWS Step Functions state machines.
-
Container asset changes of Amazon ECS services.
-
Website asset changes of Amazon S3 bucket deployments.
-
Source and environment changes of AWS CodeBuild projects.
-
VTL mapping template changes for AWS AppSync resolvers and functions.
-
Schema changes for AWS AppSync GraphQL APIs.
Usage of certain CloudFormation intrinsic functions are supported as part of a hotswapped deployment. These include:
-
Ref
-
Fn::GetAtt
– Only partially supported. Refer to this implementationfor supported resources and attributes. -
Fn::ImportValue
-
Fn::Join
-
Fn::Select
-
Fn::Split
-
Fn::Sub
This option is also compatible with nested stacks.
Note
-
This option deliberately introduces drift in CloudFormation stacks in order to speed up deployments. For this reason, only use it for development purposes. Do not use this option for your production deployments.
-
This option is considered experimental and may have breaking changes in the future.
-
Defaults for certain parameters may be different with the hotswap parameter. For example, an Amazon ECS service’s minimum healthy percentage will currently be set at
0
. Review the source accordingly if this occurs.
Default value:
false
-
--hotswap-fallback
BOOLEAN
-
This option is is similar to
--hotswap
. The difference being that--hotswap-fallback
will fall back to perform a full CloudFormation deployment if a change is detected that requires it.For more information about this option, see
--hotswap
.Default value:
false
--ignore-no-stacks
BOOLEAN
-
Perform a deployment even if your CDK app doesn’t contain any stacks.
This option is helpful in the following scenario: You may have an app with multiple environments, such as
dev
andprod
. When starting development, your prod app may not have any resources, or the resources may be commented out. This will result in a deployment error with a message stating that the app has no stacks. Use--ignore-no-stacks
to bypass this error.Default value:
false
--logs
BOOLEAN
-
Show Amazon CloudWatch log in the standard output (
stdout
) for all events from all resources in the selected stacks.This option is only compatible with
--watch
.Default value:
true
--method, -m
STRING
-
Configure the method to perform a deployment.
-
change-set
– Default method. The CDK CLI creates a CloudFormation change set with the changes that will be deployed, then performs deployment. -
direct
– Do not create a change set. Instead, apply the change immediately. This is typically faster than creating a change set, but you lose progress information. -
prepare-change-set
– Create change set but don’t perform deployment. This is useful if you have external tools that will inspect the change set or if you have an approval process for change sets.
Valid values:
change-set
,direct
,prepare-change-set
Default value:
change-set
-
--notification-arns
ARRAY
-
The ARNs of Amazon SNS topics that CloudFormation will notify for stack related events.
--outputs-file, -O
STRING
-
The path to where stack outputs from deployments are written to.
After deployment, stack outputs will be written to the specified output file in JSON format.
You can configure this option in the project’s
cdk.json
file or at~/.cdk.json
on your local development machine:{ "app": "npx ts-node bin/myproject.ts", // ... "outputsFile": "outputs.json" }
If multiple stacks are deployed, outputs are written to the same output file, organized by keys representing the stack name.
--parameters
ARRAY
-
Pass additional parameters to CloudFormation during deployment.
This option accepts an array in the following format:
STACK:KEY=VALUE
.-
STACK
– The name of the stack to associate the parameter with. -
KEY
– The name of the parameter from your stack. -
VALUE
– The value to pass at deployment.
If a stack name is not provided, or if
*
is provided as the stack name, parameters will be applied to all stacks being deployed. If a stack does not make use of the parameter, deployment will fail.Parameters do not propagate to nested stacks. To pass parameters to nested stacks, use the
NestedStack
construct.Default value:
{}
-
--previous-parameters
BOOLEAN
-
Use previous values for existing parameters.
When this option is set to
false
, you must specify all parameters on every deployment.Default value:
true
--progress
STRING
-
Configure how the CDK CLI displays deployment progress.
-
bar
– Display stack deployment events as a progress bar, with the events for the resource currently being deployed. -
events
– Provide a complete history, including all CloudFormation events.
You can also configure this option in the project’s
cdk.json
file or at~/.cdk.json
on your local development machine:{ "progress": "events" }
Valid values:
bar
,events
Default value:
bar
-
--require-approval
STRING
-
Specify what security-sensitive changes require manual approval.
-
any-change
– Manual approval required for any change to the stack. -
broadening
– Manual approval required if changes involve a broadening of permissions or security group rules. -
never
– Approval is not required.
Valid values:
any-change
,broadening
,never
Default value:
broadening
-
--rollback
|--no-rollback
,-R
-
During deployment, if a resource fails to be created or updated, the deployment will roll back to the latest stable state before the CDK CLI returns. All changes made up to that point will be undone. Resources that were created will be deleted and updates that were made will be rolled back.
Specify
--no-rollback
to turn off this behavior. If a resource fails to be created or updated, the CDK CLI will leave changes made up to that point in place and return. This will leave your deployment in a failed, paused state. From here, you can update your code and try the deployment again. This may be helpful in development environments where you are iterating quickly.If a deployment performed with
--no-rollback
fails, and you decide that you want to rollback the deployment, you can use thecdk rollback
command. For more information, see cdk rollback.Note
With
--no-rollback
, deployments that cause resource replacements will always fail. You can only use this option value for deployments that update or create new resources.Default value:
--rollback
--toolkit-stack-name
STRING
-
The name of the existing CDK Toolkit stack.
By default,
cdk bootstrap
deploys a stack namedCDKToolkit
into the specified AWS environment. Use this option to provide a different name for your bootstrap stack.The CDK CLI uses this value to verify your bootstrap stack version.
--watch
BOOLEAN
-
Continuously observe CDK project files, and deploy the specified stacks automatically when changes are detected.
This option implies
--hotswap
by default.This option has an equivalent CDK CLI command. For more information, see cdk watch.
Examples
Deploy the stack named MyStackName
$
cdk deploy MyStackName --app='node bin/main.js'
Deploy multiple stacks in an app
Use cdk list
to list your stacks:
$
cdk list
CdkHelloWorldStack CdkStack2 CdkStack3
To deploy all stacks, use the --all
option:
$
cdk deploy --all
To choose which stacks to deploy, provide stack names as arguments:
$
cdk deploy CdkHelloWorldStack CdkStack3
Deploy pipeline stacks
Use cdk list
to show stack names as paths, showing where they are in the pipeline hierarchy:
$
cdk list
PipelineStack PiplelineStack/Prod PipelineStack/Prod/MyService
Use the --all
option or the wildcard *
to deploy all stacks. If you have a hierarchy of
stacks as described above, --all
and *
will only match stacks on the top level. To match all
stacks in the hierarchy, use **
.
You can combine these patterns. The following deploys all stacks in the Prod
stage:
$
cdk deploy PipelineStack/Prod/**
Pass parameters at deployment
Define parameters in your CDK stack. The following is an example that creates a parameter named
TopicNameParam
for an Amazon SNS topic:
new sns.Topic(this, 'TopicParameter', { topicName: new cdk.CfnParameter(this, 'TopicNameParam').value.toString() });
To provide a parameter value of parameterized
, run the following:
$
cdk deploy --parameters "MyStackName:TopicNameParam=parameterized"
You can override parameter values by using the --force
option. The following is an example of
overriding the topic name from a previous deployment:
$
cdk deploy --parameters "MyStackName:TopicNameParam=parameterName" --force
Write stack outputs to a file after deployment
Define outputs in your CDK stack file. The following is an example that creates an output for a function ARN:
const fn = new lambda.Function(this, "fn", { handler: "index.handler", code: lambda.Code.fromInline(`exports.handler = \${handler.toString()}`), runtime: lambda.Runtime.NODEJS_LATEST }); new cdk.CfnOutput(this, 'FunctionArn', { value: fn.functionArn, });
Deploy the stack and write outputs to outputs.json
:
$
cdk deploy --outputs-file outputs.json
The following is an example of outputs.json
after deployment:
{ "MyStack": { "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:MyStack-fn5FF616E3-G632ITHSP5HK" } }
From this example, the key FunctionArn
corresponds to the logical ID of the CfnOutput
instance.
The following is an example of outputs.json
after deployment when multiple stacks are
deployed:
{ "MyStack": { "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:MyStack-fn5FF616E3-G632ITHSP5HK" }, "AnotherStack": { "VPCId": "vpc-z0mg270fee16693f" } }
Modify the deployment method
To deploy faster, without using change sets, use --method='direct'
:
$
cdk deploy --method='direct'
To create a change set but don’t deploy, use --method='prepare-change-set'
. By default, a change set
named cdk-deploy-change-set
will be created. If a previous change set with this name exists, it will be
overwritten. If no changes are detected, an empty change set is still created.
You can also name your change set. The following is an example:
$
cdk deploy --method='prepare-change-set' --change-set-name='MyChangeSetName'