Following up on this comment, this issue is an initial spec for a new CLI command called (for now) cdk package.

Similarly to the cloudformation package and sam package commands, the new cdk package STACK will:

1. Build local assets (docker images, zip directories) defined in a cloud assembly,
2. Upload them to S3/ECR and
3. Upload the CloudFormation template for that stack to S3, with the asset CloudFormation parameters default values set to point to the publish locations.
4. It will then return an S3 URL (presigned?) that is a self-contained template that can be deployed to the environment with no additional information required. Another interesting benefit of the self-contained template is that it represents a "point in time", which can be easily rolled back if needed.

Currently this process is performed by cdk deploy. Decoupling package from deploy is required in order to mitigate risks related to running docker build in an environment that has administrative privileges, and also to allow using of native cloudformation APIs for deployments, instead of requiring to run a container with cdk deploy. This addresses users's concern around costs and constraints the administrative IAM role in remote accounts to the cloudformation service principal).

Similar to the approach we took with cdk synth (which produces a cloud assembly as an output), cdk deploy will automatically invoke cdk package but it will also be possible to invoke them independently (similar to cdk synth). We can decide that if --app points to an s3:// url, cdk deploy will treat it as a ready-to-deploy template.

The eventual flow will be:

[cdk synth] => cdk.out(cloud-assembly) => [cdk package] => s3://template-url => [cdk deploy] => stack