Allow an app alias to be set in cdk.json

[aaronsturm]

I did try and search for open issues on this. My apologies if one already exists.
I would like the cdk.json file to allow for multiple app entries. Currently it defaults to only "app" in cdk.json and if I want to override that, I need to remember a long string:
cdk --app "npx ts-node bin/hello-cdk.ts" ls. I propose that a custom alias can be set in the cdk.json file.

Use Case

This would allow me to separate and process my stacks using a memorable alias vs the whole command.

Proposed Solution

I propose that an app alias can also be specified in cdk.json. As an example:

{
  "app": "npx ts-node bin/cdk.ts",
  "helloWorld": "npx ts-node bin/hello-cdk.ts"
}

which would allow me to call
cdk --app helloWorld ls.

Other

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[eladb]

I like this idea!

[rix0rrr]

Can I ask what the different apps do, and why you don't want to combine them into a single app?

[aaronsturm]

@rix0rrr - We have our core application CDK file, and then we have CDK files that are related to the application, but not directly. As an example, app.ts is for the application's infracture and then users.ts for our internal users and their respective permissions for console/API access. If we have a change in our staff, I update users.ts and deploy that stack change specifically.

As to why I don't combine them, they're logically separate in my mind so it makes sense to me for the files/entrypoint to be different vs having one large cdk.ts.

I hope that helps clarify my thought processes. Let me know if you have additional questions. Thanks!

[DJAlPee]

I have another use case for a feature like that:

For rolling out a static (SPA) website, we need to create resources in two regions (ACM certs / Lambda@Edge in us-east-1 for CloudFront and everything else like S3, etc. in our region). Because CDK (and CloudFormation) can't pass references across stacks, which are across different regions, I would split these resources into two different apps and handle passing the references somehow else.

[g360Joshua]

any update on this?

[TheRealAmazonKendra]

Related: #9346

[github-actions]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[jdpst]

This would be a very useful feature for managing logically distinct applications from the same repo. Our use case is that we have several web applications that are deployed from within a monorepo. Because we are leveraging the Asset constructs for S3 and lambda deployments, synthing requires the build artifacts. Having a single cdk executable would force us to build every site to deploy any of them, which is expensive (CI minutes aren't free!).

To work around this, we have a single stack that defines the infra and we deploy it using environment variables to specify which site to deploy. This works because the sites all have the same basic infra requirements, but it is not very transparent or elegant–our config settings are spread out across (in our case GitHub actions) CI scripts instead of in our CDK app.

With this solution we would be able to manage this situation much more explicitly with a different cdk executable file per logically separate application.

[ajhool]

Another use case:

We would like to deploy one "baseline" app into each AWS account that defines expensive resources (eg. VPC, RDS, etc.) that are shared across cheap feature environments in the account (eg. 5 feature-branch API gateways or websites might share the same backend database).

1. CDK Baseline App | VPC + Database | 1 app deployment per account named "Baseline"
2. CDK feature branch| API Gateway + Website | N apps named "Application-FEATURE_A" ... "Application-FEATURE_N".

The multi-region use-case is also important for us!

Those could be managed in separate repos and packages, but monorepos with a single package.json save some complexity on smaller projects. And, in theory, we could just use NestedStacks and CloudFormation to logically separate our apps -- but we'd rather not because escaping a CloudFormation issue with an API Gateway deployment is much less of a headache if databases / VPCs / stateful resources aren't involved (probably preaching to the choir here).

[billyjbryant]

My use case for this feature is housing multiple CDK Applications in a single code repository and being able to deploy them using cdk deploy from the root directory. This allows my team to manage all of its dependent applications, which are really just configurations for services like AWS Config, GuardDuty, ControlTower and other various small tools, in a single location and not have to maintain multiple code repositories.

[sciutand]

When we deploy to multiple accounts different stacks some stacks are not relevant to all accounts and often defining all stacks in the same file cause issues when trying to access secrets, vpc, stack outputs etc.
So my use case would be let's say.

bin/
     infra.ts
     workload-prod.ts
     sandbox.ts
     workload-dev.ts

and do
cdk deploy --app infra TransitGatewayStack
cdk deploy --app workload-prod WorkloadVpcStack
cdk deploy --app workload-dev WorkloadVpcStack

In essence being able to either define different app in the cdk.json file or being able to load/specify different json files.
I could achieve similar with a monorepo and something like:

packages/
      core
      infra-cdk
      workload-prod-cdk
      sandbox-cdk
      ...

but it would be a lot cleaner if cdk supported multiple apps a bit better than the current --app option

[sigpop]

We would like to deploy one "baseline" app into each AWS account that defines expensive resources (eg. VPC, RDS, etc.) that are shared across cheap feature environments in the account (eg. 5 feature-branch API gateways or websites might share the same backend database).

I have a similar use case. Having app be aliased would be useful for us.