Concepts

The @aws/nx-plugin is an Nx plugin that provides a toolkit for building and deploying full-stack applications on AWS. It gives you a collection of Generators which scaffold production-ready application code and the infrastructure to deploy it — type-safe, locally runnable, and ready to ship.

Rather than starting from a blank page, you (or your AI agent) pick the components you need — APIs, websites, authentication, AI agents, infrastructure — provide a few configuration options, and the plugin generates best-practice starter code. It even wires projects together for you (including updating existing files via AST transforms) to produce type-safe clients between your frontend and backend.

Built on Nx and its generators

Nx is a smart build framework for managing monorepos. It is language agnostic, letting TypeScript, Python, infrastructure and more live and build together in a single workspace. Its build system uses caching and dependency graph analysis to only rebuild what changed and run tasks in parallel, keeping testing, linting and building fast as your workspace grows.

Every piece of functionality in the @aws/nx-plugin is delivered as an Nx Generator — automated scaffolding that produces consistent code structures from predefined templates. Generators can be invoked via the Nx CLI, the Nx Console IDE plugin, or by your AI assistant through the Nx Plugin for AWS MCP Server.

Because every component is a generator, you only add what you need, when you need it. Start with an API, add a website later, connect them when you’re ready — each step is a single command.

Build with proven frameworks

The @aws/nx-plugin deliberately avoids building custom abstractions on top of the tools you already know. Instead of inventing bespoke frameworks, runtimes or wrappers, it scaffolds idiomatic code using established, widely-adopted open-source projects. This means your existing skills carry over directly, you can rely on the official documentation for each framework, and you’re never locked into a layer that only this plugin understands.

The generated code stands on the shoulders of best-in-class frameworks, including:

ReactViteshadcn/uitRPCFastAPISmithyStrands AgentsMCPAWS CDKTerraform

The plugin’s value is in how these pieces are configured and connected together for AWS — not in replacing them.

Open for modification

All generated code is your code. The @aws/nx-plugin is a build-time tool, not a runtime dependency — once a generator has run, the plugin is no longer in the picture. You can read every file it produced, commit it, and change it however you like.

This means:

• No escape hatches. There’s no proprietary configuration surface to learn or wrestle with when you need to do something the generator didn’t anticipate. You edit the generated code directly, the same way you would edit any code you wrote yourself.
• No new layers of abstraction. Generators emit plain, idiomatic code for the underlying frameworks. There’s no wrapper API or magic indirection sitting between you and React, tRPC, FastAPI, CDK or any of the other tools — what you see is what runs.
• The plugin isn’t a dependency. It generates code and steps out of the way. Your application doesn’t import or rely on @aws/nx-plugin at runtime, so you’re never blocked by it and never locked in.

If you don’t like something in the generated code, you are free to modify it. Generators give you a head start, not a cage.

In step with improvements

Owning your code usually comes at a cost: the moment you start editing a scaffold, you’re cut off from the fixes and improvements made upstream. Adopting them again means reading a changelog, regenerating, and reconciling a diff by hand. Migrations are how the @aws/nx-plugin works to keep that from happening.

Releases ship migrations alongside them, aiming to bring the code earlier generators produced into step with the improvements we’ve made since. When we fix a bug, harden a security default or refine a generated pattern, running nx migrate applies that change to your code, in place — instead of leaving you to spot it in a changelog and port it across yourself.

In practice:

• Upgrading is automated, not a re-adoption exercise. A workspace generated months ago can move forward with the plugin rather than drifting further from it.
• Customisations are pattern-matched, not overwritten. Migrations check that a file still matches the shape the generator produced. Where it has diverged beyond what they can safely update, they leave your code alone and report the manual follow-up instead.
• Some changes arrive as agent prompts. Where the right edit depends on what you’ve built, the migration is a prompt your AI coding agent applies rather than a codemod.
• Upgrades are opt-in. Nothing in your workspace changes until you choose to run nx migrate.

Migrations narrow the gap rather than close it: how far your code has moved decides how much they can do, and some steps will still need your hands.

Minimal dependencies

The @aws/nx-plugin strives to keep the number of global dependencies to a minimum. What you need to get started boils down to which generators you invoke.

As an example, any TypeScript-based generator will only require Node to be installed. For Python-based projects, UV is the only requirement.

Type safety

The @aws/nx-plugin employs type-safety to simplify the developer experience via IDE completions, while also eliminating runtime errors which would otherwise only surface in a non type-safe implementation. As such, all components that are vended are type-safe by default.

Type safety flows across project boundaries: when you connect a website to an API, the generated client shares types with the backend, so a change to an API contract surfaces as a compile-time error in your frontend rather than a bug in production. Refactor with confidence.