Run the Amplify CLI From Source: Fixing Gen 1 Bugs Yourself

Why This Matters for Gen 1

Amplify Gen 1 is in maintenance mode. The AWS Amplify maintenance policy explains what that means in practice: releases are limited to critical bug fixes and security issues, and no new features ship. The Gen 1 documentation states that Gen 1 reaches end of life on May 1, 2027. AWS recommends starting new projects on Gen 2 and migrating existing ones using the migrate to Gen 2 guide. Even so, Gen 2 isn't a near-term option for every team, and plenty of teams have good reasons to stay on Gen 1 for now.

A product that's frozen on features is exactly where building from source pays off. If a bug is blocking you and there's a known fix, you can run that fix yourself instead of waiting for a release that may never come. The steps are always the same:

1. Clone the CLI from source.
2. Patch the code path that's failing.
3. Build your local copy.
4. Run your build against your project instead of the globally installed CLI.

That pattern is the real takeaway here. The bug below is just something concrete to apply it to.

Before you commit to this, know that once you build your own copy, you own it. Read Limitations and Caveats first.

The Bug We'll Fix

We'll use a small, self-contained bug as the example. On a large Gen 1 schema, adding or changing a GSI fails during an iterative deployment with:

🛑 table name should be passed

The cause is one API call. The CLI looks up DynamoDB table names with CloudFormation's DescribeStackResources, which returns at most 100 resources and doesn't paginate. On a big schema (roughly 90 or more @model types), some resources fall past that 100-item limit, so the lookup comes back empty and the deploy stops. The fix is a one-function change: switch to the paginated ListStackResources API. That's all we need to demonstrate the pattern.

Walking the Pattern: Clone, Patch, Build, Run

Step 1: Clone the Amplify CLI

git clone https://github.com/aws-amplify/amplify-cli.git
cd amplify-cli
git checkout -b fix/paginate-describe-stack-resources dev

Step 2: Apply the Fix

Edit packages/amplify-provider-awscloudformation/src/utils/amplify-resource-state-utils.ts and replace the resource fetching logic in the getTableNames function.

Before:

import { CloudFormationClient, DescribeStacksCommand, DescribeStackResourcesCommand, Capability } from '@aws-sdk/client-cloudformation';

// ...

const describeStackResourcesCommand = new DescribeStackResourcesCommand({
  StackName: StackId,
});
const apiResources = await cfnClient.send(describeStackResourcesCommand);
for (const resource of apiResources.StackResources) {

After:

import {
  CloudFormationClient,
  DescribeStacksCommand,
  ListStackResourcesCommand,
  Capability,
} from '@aws-sdk/client-cloudformation';

// ...

// Use ListStackResources instead of DescribeStackResources to support pagination.
// DescribeStackResources is capped at 100 results with no pagination support,
// which causes failures for stacks with over 100 resources (for example, schemas with 90+ @model types).
let nextToken: string | undefined;
const allResources: { LogicalResourceId?: string; PhysicalResourceId?: string }[] = [];
do {
  const listStackResourcesCommand = new ListStackResourcesCommand({
    StackName: StackId,
    NextToken: nextToken,
  });
  const response = await cfnClient.send(listStackResourcesCommand);
  if (response.StackResourceSummaries) {
    allResources.push(...response.StackResourceSummaries);
  }
  nextToken = response.NextToken;
} while (nextToken);

for (const resource of allResources) {

This is the part that changes from bug to bug. Everything else in this guide stays the same no matter what you're fixing.

Step 3: Build the CLI

The monorepo uses Yarn 3.5.0. Your global yarn version may conflict with it, so use the bundled one directly:

# Create a wrapper to use the repo's bundled Yarn 3.5.0
mkdir -p .bin
echo '#!/usr/bin/env bash' > .bin/yarn3
echo 'exec node "$(dirname "$0")/../.yarn/releases/yarn-3.5.0.cjs" "$@"' >> .bin/yarn3
chmod +x .bin/yarn3

# Install and build
.bin/yarn3 install
.bin/yarn3 setup-dev

If setup-dev fails on amplify-graphiql-explorer (a known Node 18 issue with crypto), don't worry about it. That package isn't needed for amplify push. Create the symlink manually instead:

mkdir -p .bin
ln -sf "$(pwd)/packages/amplify-cli/bin/amplify" .bin/amplify-dev

Check that it works:

.bin/amplify-dev --version

Step 4: Use the Patched CLI

From your Amplify project directory, run the patched CLI instead of the one installed globally:

cd ~/your-amplify-project
~/path-to/amplify-cli/.bin/amplify-dev push

That's the whole loop. Clone, change one file, build, and run your copy.

Did It Work?

Run your normal command (here, amplify push) with the patched CLI and confirm the failure is gone. For this bug, the stock v14.3.0 CLI stops with table name should be passed, and the patched build deploys cleanly. Your results depend on your own schema and resource count, so test against a non-production environment first.

Limitations and Caveats

Building your own CLI is a real way out of a jam, but it comes with costs. Know these before you rely on it:

• You own the fork. Once you build from source, keeping it current is on you. Fixes that ship upstream won't reach you unless you pull and rebuild.
• Patched builds aren't officially supported. AWS Support helps with the released CLI. A build you've modified locally is out of scope, so reproduce any issue on a stock release before you escalate.
• It drifts from the rest of your team. A fix on your machine doesn't help your teammates or your CI. If the patched CLI is required to deploy, every developer and pipeline needs the same build. Consider publishing an internal package or putting the build in a container so the environment is reproducible.
• The official fix may look different. If the Amplify team ships their own fix, it may not match yours. Plan to drop your local change and move back to the released CLI once a fixed version is out.
• This is a Gen 1 stopgap with a deadline. Gen 1 reaches end of life on May 1, 2027. A local patch buys you time, but weigh that effort against the Gen 2 migration you'll need eventually.

The bigger point is that building the CLI from source turns "we're stuck until AWS ships a fix" into "we can fix this ourselves if we have the fix." Use it on purpose, write down what you changed, and keep a path back to the official release.

References

• AWS Amplify maintenance policy, for what maintenance mode covers
• AWS Amplify Gen 1 documentation, which states the May 1, 2027 end-of-life date
• Migrate to Gen 2 guide
• CloudFormation DescribeStackResources API, which documents the 100-resource limit
• CloudFormation ListStackResources API, the paginated alternative