cdk deploy v7-Stack requires Docker due to v8-Stack synthesis

[qops1981]

I deploy this project in CircleCI using a container-based executor (no Docker daemon available). I use the following command:

  overrideWarningsEnabled=false npx cdk deploy v7-Stack \
    --parameters DeployDemoUIParameter=No \
    --parameters LogRetentionPeriodParameter=${LOG_RETENTION} \
    --parameters CloudFrontPriceClassParameter=PriceClass_100 \
    --parameters AutoWebPParameter=Yes \
    --parameters CorsEnabledParameter=Yes \
    --parameters CorsOriginParameter="${CORS_ORIGINS}" \
    --parameters SourceBucketsParameter=${SOURCE_BUCKET} \
    --profile ${ENVIRONMENT} \
    --require-approval never

Even though I'm only deploying v7-Stack, CDK synthesizes all stacks in the app — including v8-Stack, which contains a DockerImageAsset. This triggers a docker build during synthesis and fails in environments without Docker:

ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
v7-Stack: fail: docker build --tag cdkasset-febb4e1b263361e89ae71e47ca4a8de2c65388a5534fe76f71760e44e2685d9a --file Dockerfile --platform linux/amd64 .
exited with error code 1

I can work around this by switching to a VM executor with Docker available, but it feels unnecessary since I only need v7-Stack.

Is there a recommended way to deploy just v7-Stack without triggering the v8 Docker build? For example, would it be possible to split the stacks into separate CDK apps, or add a context flag to conditionally skip v8-Stack instantiation?

[qops1981]

I had AI rewrite my question. Hopefully its more clear 🤷‍♂️

[bios6]

Thanks for raising this issue, we will take a look at this and get back to you.

[bryceaug]

Hey @qops1981, thanks for surfacing this issue to us.

I was able to reproduce the issue you are seeing. We will take a look at restructuring how our deployment paths coexist to prevent the Lambda deployment having an indirect dependency on Docker.

This issue is coming from the absence of a productionImageUri value, which is used by the ECS path's ContainerConstruct when determining whether to use a local image or external image url. Using this mechanism you should be able to "trick" cdk synth by providing a dummy value either when running cdk deployor in your cdk.json config.

1 - Add -c productionImageUri="placeholder:latest" to your cdk deploy
Ex:

overrideWarningsEnabled=false npx cdk deploy v7-Stack \
  -c productionImageUri="placeholder:latest" \
  --parameters DeployDemoUIParameter=No \
  --parameters LogRetentionPeriodParameter=${LOG_RETENTION} \
  --parameters CloudFrontPriceClassParameter=PriceClass_100 \
  --parameters AutoWebPParameter=Yes \
  --parameters CorsEnabledParameter=Yes \
  --parameters CorsOriginParameter="${CORS_ORIGINS}" \
  --parameters SourceBucketsParameter=${SOURCE_BUCKET} \
  --profile ${ENVIRONMENT} \
  --require-approval never

2 - Add productionImageUri to your cdk.json:

 "context": {
    "productionImageUri": "placeholder:latest",
    ...existing context...
  }

Since you are deploying the Lambda template, the dummy URL used in the ECS template will not cause any issues with your deployment.

Let me know if you continue to see issues.