What does the Angular CLI's `ng deploy` command actually run, and where does its behaviour come from?

## An architect command with no built-in builder The Angular CLI's commands `ng build`, `ng serve`, `ng test` and `ng deploy` are **architect commands**: each runs a named **target** of a project in `angular.json`, and the target names a **builder** that does the work. `ng deploy` runs the target called `deploy`. What makes `ng deploy` different is that a new workspace has **no `deploy` target**, and the Angular CLI ships no deploy builder. The command is a hook for third-party packages. ## Where the target comes from Hosting providers and community projects publish packages that contain both an `ng add` schematic and a deploy builder. Running `ng add <package>`: 1. installs the package; 2. runs its schematic, which adds a `deploy` target to the selected project in `angular.json`, for example `"deploy": { "builder": "<package>:deploy", "options": { ... } }`; 3. may prompt for account or project details and write them into the options. From then on, `ng deploy` runs that builder. The command's own documentation puts it this way: "use `ng add` to add a package that implements deployment capabilities to your favorite platform". ## What a typical deploy builder does The builder is ordinary code with access to the workspace, so behaviour varies, but most follow the same pattern: - build the project, usually with the `production` configuration; - upload the build output (the `browser` folder, or the whole output for server builds) to the provider; - print the resulting URL. Options such as the target site, the build configuration or a base href are the builder's own; read the package's documentation, because `ng deploy` passes them through untouched. ## When there is no deploy target Running `ng deploy` in a project without the target does not fail silently. The CLI reports: ```text Cannot find "deploy" target for the specified project. You can add a package that implements these capabilities. ``` It follows with example `ng add` commands, and in an interactive terminal it prompts you to pick one and runs `ng add` for it. In CI, with no terminal, it just prints the message and exits with an error. ## Deploying to your own infrastructure You have two reasonable options: | Approach | When it fits | |---|---| | A custom builder registered as the `deploy` target | several projects share the same deployment logic and developers expect `ng deploy` to work | | A CI job running `ng build` and copying `dist/<project>` | most teams; deployment stays in the pipeline, visible and auditable | Writing the builder itself (the builder API, `createBuilder` and builder schemas) is the custom-builders topic. For the deploy target, only the contract matters: the target's `builder` names your package's builder and its `options` are validated by that builder's schema. ## Using it safely in a team - **Keep credentials out of `angular.json`.** Deploy targets are committed with the workspace; tokens belong in environment variables or the CI secret store, as the package allows. - **Pin the deploy package's version.** Its behaviour is the package's, so an unpinned upgrade can change what `ng deploy` does. - **Prefer non-interactive runs in CI.** Interactive prompts that work on a laptop stall or fail in a pipeline; check which options the builder offers to skip them. - **Know which configuration it builds.** Some builders build the production configuration themselves, others deploy whatever output already exists. ## Interview angle The point interviewers look for is that `ng deploy` is **not magic**: it is one line in `angular.json` pointing at someone else's code. That explains why its flags differ between providers, why it can be replaced by a script, and why a deploy that suddenly behaves differently after an `npm update` usually traces back to the deploy package, not to the Angular CLI.