Storage dependency undefined in custom resource on amplify init

[chriswaterbury]

How did you install the Amplify CLI?

npm

If applicable, what version of Node.js are you using?

22

Amplify CLI Version

14.0.0

What operating system are you using?

Amplify Hosting Default Linux

Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.

No manual changes made

Describe the bug

When adding a dependency on storage to a custom CDK resource (Gen 1), the dependencies.storage is undefined when running amplify init in environment in Amplify Hosting CI/CD.

Example dependencies code

const dependencies = AmplifyHelpers.addResourceDependency(this,
      amplifyResourceProps.category,
      amplifyResourceProps.resourceName,
      [
        {
          category: 'storage',
          resourceName: {files-resource-name}
        },
      ]
    )

This appears to be caused by custom resource being built BEFORE storage, so the storage dependency is undefined when you amplify init an environment without resources already built.

I didn't see this error when building locally because storage was already built locally when I added the custom resource and storage dependency was never undefined.

Expected behavior

Adding a dependency on storage to a custom resource should not be undefined if storage isn't already built.

Reproduction steps

1. Initialize new amplify project
2. Add storage/auth resources
3. Delete the build folders to simulate CI/CD environment
4. Add custom CDK resource
5. Add dependency on storage in cdk-stack.ts
6. Run amplify init
7. Storage dependency is undefined

Project Identifier

I managed to get around this in my environment by returning if the storage dependency is undefined, but I don't have the issue with dependencies on API for example.

Log output

Details

# Put your logs below this line

2025-12-02T13:15:08.976Z [WARNING]: - Building resource auth/{resource-name}
304
2025-12-02T13:15:13.673Z [WARNING]: - Building resource auth/{resource-name}
305
2025-12-02T13:15:18.502Z [WARNING]: - Building resource custom/{resource-name}
306
2025-12-02T13:15:18.507Z [WARNING]: - Building custom resources
307
2025-12-02T13:15:30.881Z [WARNING]: - Building resource custom/{resource-name}
308
                                    - Building custom resources
309
2025-12-02T13:15:40.607Z [WARNING]: - Building resource custom/{resource-name}
310
                                    - Building custom resources
311
2025-12-02T13:15:50.742Z [WARNING]: ✖ Initializing your environment:{env-name}
312
2025-12-02T13:15:50.746Z [WARNING]: ✖ There was an error initializing your environment.
313
2025-12-02T13:15:50.746Z [INFO]: 🛑 There was an error building the custom resources
314
                                 Cannot read properties of undefined (reading 'storage-resource-name')

Additional information

No response

Before submitting, please confirm:

• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
• I have removed any sensitive information from my code snippets and submission.

[pahud]

Hi @chriswaterbury,

Thank you for reporting this issue. Based on the logs and reproduction steps, this appears to be a build ordering problem in CI/CD environments where custom resources are being built before their storage dependencies.

The issue occurs because during amplify init in a fresh environment, the build system processes resources in a sequence that doesn't account for the dependency relationships declared via AmplifyHelpers.addResourceDependency. When your custom resource tries to access dependencies.storage, the storage resource hasn't been built yet, resulting in undefined values.

Workaround:
From my view, your current approach of checking if the dependency is undefined before using it is a reasonable temporary solution:

if (dependencies.storage?.yourStorageResource) {
 // Use the storage dependency
}

Root Cause:
The buildCustomResources function doesn't enforce dependency build order. It builds custom resources based on resource status rather than dependency topology.