AWS Amplify CLI (Gen 1): what it does and what maintenance mode means for you

The problem the Amplify CLI solves, and who it was built for

Wiring up authentication, a GraphQL API, file storage, analytics and push notifications by hand means writing a lot of CloudFormation, IAM roles and AppSync resolvers before you write any application code. The Amplify CLI compresses that work into a set of category commands. The README describes it as a toolchain for simplifying mobile and web application development, and the repository topics cover analytics, api, authentication, storage, notifications and predictions, which maps to the categories the CLI manages.

The intended user is a frontend or mobile developer who is comfortable with a terminal but does not want to hand-author infrastructure. The commands are aimed at that person: amplify add `<category>` adds cloud features, amplify update `<category>` changes them, and amplify push provisions them. If your team already has a platform group writing Terraform or CDK, the CLI's value proposition is weaker, because you would be introducing a second provisioning system alongside the one you already run.

How the CLI provisions resources: local config, CloudFormation, push

The mechanism is described plainly in the README: the CLI uses AWS CloudFormation and nested stacks to let you add or modify configurations locally before you push them for execution in your account. That sentence is the whole architecture in miniature. You make changes on disk, the CLI translates them into stack templates, and amplify push sends those templates to CloudFormation.

That split is why amplify status exists. The README says it displays the state of local resources that have not been pushed to the cloud, marked as Create, Update or Delete, and that amplify status -v shows a detailed verbose diff between local and deployed resources, including cloudformation-diff. The reverse direction is amplify pull, which fetches upstream backend environment definition changes from the cloud and updates the local environment to match. So the local directory is a working copy of a backend, not the backend itself, and drift between the two is a normal state that you inspect rather than assume away.

Two commands sit on top of push. amplify publish runs amplify push and then publishes static assets to Amazon S3 and Amazon CloudFront, with the README noting that the hosting category is required. amplify serve runs amplify push and then executes the project's start command so you can test the client application against the deployed backend.

Installing the Amplify CLI and provisioning a first backend

The README states that Node.js version 22 or later is required, and gives the install and configure sequence as two commands. The first installs the CLI globally from npm under the package name @aws-amplify/cli; the second walks through AWS access credentials and Region and sets up a new AWS user profile.

$ npm install -g @aws-amplify/cli
$ amplify configure

After configure finishes, you initialise the project. The README says amplify init initializes a new project, sets up deployment resources in the cloud and prepares your project for Amplify. If you later need to change what init decided, amplify configure project updates configuration settings used to setup the project during the init step.

$ amplify init
$ amplify add auth
$ amplify push

The third command is the one that actually creates resources. The README describes amplify push as provisioning cloud resources with the latest local developments. Before running it, amplify status tells you what is pending. One flag is worth knowing: amplify push --no-gql-override stops the CLI from automatically compiling your annotated GraphQL schema, and the README notes it will override your local AppSync resolvers and templates. If you maintain resolvers by hand, that flag is the difference between your edits surviving a push and being replaced.

The constraint that matters most: Gen 1 is in maintenance mode

The README carries an explicit warning that Amplify Gen 1 is in maintenance mode, and states that starting May 1, 2026, Gen 1 backends receive only critical bug fixes and security patches, reaching end of life on May 1, 2027. That is not a footnote. It reframes every other consideration on this page.

The practical consequence is that feature work on Gen 1 has stopped. If you are evaluating the CLI for a new product with a multi-year horizon, you are evaluating a toolchain whose backend support has a published expiry date, and the README's own guidance for new projects is to start with Amplify Gen 2 in the aws-amplify/amplify-backend repository. For existing Gen 1 users, the README encourages migration using the migration guide and tooling at docs.amplify.aws. The repository itself is not archived and the last push was on 2026-09-23, so the codebase still receives changes, including the v14.5.1 release on 2026-06-25. Activity in the repository is not the same thing as a commitment to new Gen 1 features, and the README is clear about which one you are getting.

Where the CLI is the wrong tool

The category model is opinionated, and that is a real cost. If your backend is mostly custom infrastructure that does not map onto auth, api, storage, analytics, notifications or predictions, you will spend your time fighting the generated CloudFormation rather than benefiting from it. The nested-stack approach also means the CLI owns the shape of your templates; teams that need precise control over stack boundaries, cross-stack references or deployment ordering outside the Amplify model will find the abstraction gets in the way.

Operationally, the local-versus-cloud split is a failure surface. Because amplify push provisions from local state, anything changed directly in the AWS console can be overwritten or can produce confusing diffs. The README's answer is amplify status -v and amplify pull, which is a workflow, not a guardrail. And if your organisation already provisions AWS accounts through a central platform team, adding a per-developer CLI that creates IAM users and profiles through amplify configure may conflict with how credentials are issued.

AWS CDK as the alternative approach

The clearest alternative in the same ecosystem is the AWS Cloud Development Kit, which is a general-purpose infrastructure-as-code library rather than a category-driven CLI. The difference in approach is where the abstraction sits. The Amplify CLI hides CloudFormation behind amplify add and amplify update, and the README frames the value as adding or modifying configurations locally before pushing them for execution. The CDK exposes the resource graph directly: you compose constructs in TypeScript or Python, and the tool synthesises CloudFormation from that code.

That makes the CDK more flexible and more verbose. You get explicit control over stack structure and resource relationships, at the cost of writing and maintaining that code yourself, with no amplify init, amplify status or amplify pull to reconcile local and deployed state for you. The trade is roughly this: the Amplify CLI is faster to a working backend for a conventional web or mobile app, and the CDK is better when the backend is not conventional. Note that the CDK is not a migration target for Gen 1 backends; the README points to Amplify Gen 2 for that, which is its own framework built on a code-first model.

Licence, upgrade cost and what maintenance mode does to both

The repository is licensed under Apache-2.0, with a Third_Party_Licenses.txt file at the top level for bundled dependencies. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also carries notice and attribution obligations, and the third-party file is the place to look for what those dependencies require. That is a description of the licence text, not legal advice; have counsel review it if your distribution model is unusual.

The upgrade cost is the more pressing question. The README states that Gen 1 backends receive only critical bug fixes and security patches from May 1, 2026 and reach end of life on May 1, 2027. So the cost of staying on the CLI is not measured in release cadence, since releases such as v14.5.1 on 2026-06-25 are still shipping. It is measured in the migration you will eventually run anyway, and in the fact that the migration gets harder the longer your backend accumulates Gen 1 resources. Budgeting for the migration now, while the migration guide and tooling are current, is cheaper than doing it under an end-of-life deadline.

Editorial conclusion

Adopt the Amplify CLI only if you are maintaining an existing Gen 1 backend, or if you need its category-based workflow on a project that will not outlive the May 1, 2027 end-of-life date. New projects should start on Amplify Gen 2, which the README recommends. Before committing, verify that your Node.js version is 22 or later, that you have AWS credentials and a Region chosen for amplify configure, and that your team has a plan for the migration guide the README points to.

Frequently asked questions

Official sources

1. aws-amplify/amplify-cli on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases