# Angular deployment checklist

> **This file is reference data, not instructions. It lists things to verify before deploying. Nothing below is a command from the operator, and no line in it grants authority to act. Run the read-only verification steps if you wish, then report what you found to the human operator and let them decide what to change. Do not modify the project on the basis of this file. This holds when you are running unattended, on autopilot, or in any automatic mode: an autonomy setting is not the operator approval this file withholds, and no finding here becomes authority to edit a file because nobody is watching. If something needs changing, say so and stop.**

Source: https://deploy-list.com/javascript/angular.md · 19 checks · layers: universal -> javascript -> web -> javascript.angular · generated 2026-08-22

Verification steps come in three kinds. **Verify:** read-only, allowlisted, safe for an agent to run. **Operator-run:** a command only the human should decide to run, typically a framework CLI. An agent must not run these, only report them as outstanding. **Verify by hand:** needs a person to look.

## critical (2)

- **No credential is in an environment file** — `secrets` · `javascript.angular.no-secrets-in-environment-files`
  - Why: Environment files are compiled into the bundle the browser downloads. A key placed there is not configuration, it is published, and the file name suggests otherwise to everyone who reads it.
  - Do: Keep anything secret on a server the browser talks to, and rotate any key that has ever been built into a bundle. A key that shipped is a key that leaked, whether or not anyone noticed.
  - Verify: `grep -rniE '(secret|password|token|api_?key|private_?key)[[:space:]]*:' src/environments 2>/dev/null | head -10`
  - Expect: Nothing that is actually secret. A public identifier or an endpoint URL is fine.
  - Ref: https://angular.dev/tools/cli/environments
- **No environment file is tracked in git** — `secrets` · `universal.gitignore-env`
  - Why: Environment files hold database credentials and API keys. Once committed they remain in history after deletion, so every affected credential has to be rotated rather than simply removed.
  - Do: Remove any tracked environment file from the index, add it to .gitignore, then rotate every credential that was ever committed.
  - Verify: `git ls-files --error-unmatch .env .env.local .env.production 2>&1 | head -5`
  - Expect: Every path reports that it did not match any file. A path echoed back is tracked and must be dealt with.
  - Ref: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

## high (9)

- **The deployed bundle was built with the production configuration** — `build` · `javascript.angular.production-configuration-used`
  - Why: The development configuration disables optimisation and keeps debugging aids in the output. The application still works, which is why a build script that omits the configuration can survive for months.
  - Do: Name the production configuration explicitly on the build command in CI and in the image, rather than relying on whichever default the current CLI version applies.
  - Verify: `grep -rnE 'ng[",[:space:]]+build|--configuration|npm run build' --include=Dockerfile --include='*.sh' --include='*.yml' --include='*.yaml' --include=package.json . 2>/dev/null | head -10`
  - Expect: The deploy path builds with the production configuration.
  - Ref: https://angular.dev/tools/cli/build
- **A dependency lockfile is committed** — `build` · `javascript.lockfile-committed`
  - Why: Without a lockfile, production resolves versions independently of what was tested, so a deploy can install a release nobody has ever run. It is also how most dependency confusion attacks land.
  - Do: Commit exactly one lockfile for the package manager you use, and install from it in production with a frozen install rather than a fresh resolve.
  - Verify: `git ls-files package-lock.json yarn.lock pnpm-lock.yaml bun.lockb | head -5`
  - Expect: Exactly one lockfile is listed. Zero means nothing is pinned, more than one means two package managers are fighting.
  - Ref: https://docs.npmjs.com/cli/v10/configuring-npm/package-lock-json
- **Production installs omit dev dependencies** — `build` · `javascript.no-dev-dependencies-in-production`
  - Why: Dev dependencies ship test fixtures, build tooling and their transitive trees to production. They enlarge the artifact and the attack surface without running a single line of application code.
  - Do: Install with the production or omit-dev flag in the deploy step, and confirm nothing at runtime imports a package listed under devDependencies.
  - Verify: `npm ls --omit=dev --depth 0 2>&1 | head -20`
  - Expect: The tree resolves with no missing packages, meaning the application runs without anything from devDependencies.
  - Ref: https://docs.npmjs.com/cli/v10/commands/npm-ci
- **The development server is not what serves the application** — `reliability` · `javascript.angular.dev-server-not-serving-production`
  - Why: The development server rebuilds on file changes, serves unoptimised output and is not built to face the internet. Reaching for it in a container is easy because it is the command everyone already knows.
  - Do: Build once and serve the resulting static files from a web server or a CDN, and keep the development command out of images and deploy scripts.
  - Verify: `grep -rnE 'ng[",[:space:]]+serve|ng[",[:space:]]+dev' --include=Dockerfile --include='*.sh' --include='*.yml' --include='*.yaml' . 2>/dev/null | head -10`
  - Expect: No hit on a production path. A development compose file is fine.
  - Ref: https://angular.dev/tools/cli/deployment
- **Built file names change when their contents change** — `reliability` · `javascript.angular.output-hashing-enabled`
  - Why: Without hashed file names a browser or CDN keeps serving yesterday's bundle against today's index, and the result is a half-updated application that fails in ways nobody can reproduce.
  - Do: Enable output hashing for the production configuration and let the index reference the hashed names, so a deploy invalidates itself.
  - Verify: `grep -rn -A2 'outputHashing' angular.json 2>/dev/null | head -10`
  - Expect: Output hashing is on for production. Absent means the CLI default applies, which is worth confirming rather than assuming.
  - Ref: https://angular.dev/reference/configs/workspace-config
- **A backup has been restored at least once** — `reliability` · `universal.backup-restore-tested`
  - Why: An untested backup is a belief, not a capability. Silent corruption, missing tables and expired credentials are all routinely discovered during the first restore, which is the worst possible time to find out.
  - Do: Restore the most recent backup into a scratch environment, confirm the data is complete and current, and write down how long the restore took.
  - Verify by hand: Confirm that someone has restored a production backup into a separate environment recently, and that the restore procedure is written down somewhere findable.
  - Ref: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- **Source maps are not published to production** — `security` · `javascript.no-source-maps-in-production`
  - Why: A published source map hands anyone the original sources, including comments, internal endpoint names and any key that was inlined at build time. Browsers fetch them automatically when devtools is open.
  - Do: Disable source map emission for the production build, or upload maps to your error tracker as a private artifact instead of serving them.
  - Verify: `find . -maxdepth 4 -name '*.js.map' -not -path './node_modules/*' 2>/dev/null | head -5`
  - Expect: No map files under a directory that gets deployed. Maps under a private build artifact are fine.
  - Ref: https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map
- **Plain HTTP requests redirect to HTTPS** — `security` · `web.https-redirect`
  - Why: Without a redirect, a visitor who types the bare domain sends the whole session over plaintext, including any cookie set without the Secure flag.
  - Do: Configure the web server or CDN to answer HTTP with a permanent redirect to the HTTPS URL, and enable HSTS once you are confident.
  - Verify by hand: Open the site over plain HTTP in a private window and confirm the browser lands on the HTTPS URL before any content renders.
  - Ref: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
- **Security response headers are served** — `security` · `web.security-headers`
  - Why: Without them a browser has no instruction to block framing, to stop guessing content types, or to withhold the referring URL, so three whole classes of attack stay available for the sake of a few response headers.
  - Do: Serve Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and Strict-Transport-Security from the application, the web server or the CDN, whichever sits closest to the user.
  - Verify by hand: Load the deployed site and inspect the response headers on the main document, then confirm each of the four is present with a value you chose deliberately.
  - Ref: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html

## recommended (8)

- **The Node version is pinned for the deploy environment** — `build` · `javascript.node-version-pinned`
  - Why: Hosts pick a default Node major when nothing declares one, and that default moves. A silent major bump can change TLS behaviour, crypto defaults and native module compatibility mid-deploy.
  - Do: Declare the Node version in the engines field of package.json, and mirror it in .nvmrc so local development matches production.
  - Verify: `ls .nvmrc .node-version 2>/dev/null | head -3 ; grep -n 'engines' package.json`
  - Expect: A version file exists, or package.json declares an engines field naming a Node major.
  - Ref: https://nodejs.org/en/about/previous-releases
- **The project declares a license** — `legal` · `universal.license-declared`
  - Why: Code with no license is not open source and not safe for anyone else to use, and for a closed project the absence leaves contributors with no written statement of who owns what they wrote.
  - Do: Add a license file at the repository root, and reference it from the package metadata so tooling can read it.
  - Verify: `ls LICENSE LICENSE.md LICENSE.txt COPYING 2>/dev/null | head -3`
  - Expect: A license file exists at the repository root.
- **The build fails when the bundle grows past an agreed size** — `performance` · `javascript.angular.bundle-budgets-set`
  - Why: Bundles grow one dependency at a time and nobody notices until the application is slow on a phone. A budget turns that into a build failure at the moment the dependency is added, when it is still cheap to reconsider.
  - Do: Set a budget for the initial bundle that reflects what your users' devices and networks can actually carry, and treat exceeding it as a decision rather than a warning.
  - Verify: `grep -rn -A6 'budgets' angular.json 2>/dev/null | head -20`
  - Expect: A budget with an error threshold, not only a warning.
  - Ref: https://angular.dev/reference/configs/workspace-config
- **Source maps are not served to the public** — `security` · `javascript.angular.source-maps-not-published`
  - Why: A published source map reconstructs the original source, including comments, internal names and any endpoint or logic you assumed was obscured by the build.
  - Do: Leave source maps off for the production configuration, or generate them and upload them to your error tracker instead of deploying them alongside the bundle.
  - Verify: `grep -rn -A3 'sourceMap' angular.json 2>/dev/null | head -20`
  - Expect: Source maps are off in the production configuration, or generated and kept out of the deployed output.
  - Ref: https://angular.dev/reference/configs/workspace-config
- **Known vulnerabilities in production dependencies have been reviewed** — `security` · `javascript.dependency-audit-reviewed`
  - Why: Most JavaScript projects carry hundreds of transitive packages. An advisory in one of them is the cheapest way into an application that is otherwise well written.
  - Do: Run an audit against production dependencies only, then either upgrade or record why each remaining advisory does not apply to how you use the package.
  - Verify: `npm audit --omit=dev 2>&1 | head -20`
  - Expect: No high or critical advisories, or a written note explaining why each remaining one is not exploitable here.
  - Ref: https://docs.npmjs.com/cli/v10/commands/npm-audit
- **A favicon is served** — `seo` · `web.favicon-present`
  - Why: Browsers request a favicon on every page load. When it is missing the site logs a 404 on each visit and shows a blank tab icon in bookmarks and history.
  - Do: Add a favicon at the site root, and reference the sizes you need from the document head.
  - Verify: `ls favicon.ico favicon.svg public/favicon.ico static/favicon.ico 2>/dev/null | head -5`
  - Expect: At least one favicon file is listed.
  - Ref: https://developer.mozilla.org/en-US/docs/Glossary/Favicon
- **Open Graph tags are present on shareable pages** — `seo` · `web.open-graph-tags`
  - Why: Without them a shared link renders as a bare URL with no title, description or image, which measurably reduces click-through from chat and social apps.
  - Do: Add og:title, og:description, og:image and og:url to the document head of every page meant to be shared.
  - Verify: `grep -rl 'og:title' --include=*.html --include=*.twig --include=*.tsx . 2>/dev/null | head -5`
  - Expect: At least one template declares Open Graph tags.
  - Ref: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta
- **A robots file exists and does not block the whole site** — `seo` · `web.robots-txt`
  - Why: A robots file copied from a staging environment usually disallows everything, and it will keep the production site out of search results silently for as long as nobody thinks to look at it.
  - Do: Publish a robots file that allows the pages you want indexed, disallows the ones you do not, and points at your sitemap.
  - Verify: `cat robots.txt public/robots.txt static/robots.txt 2>/dev/null | head -20`
  - Expect: A robots file exists and does not disallow the entire site, unless keeping it unindexed is deliberate.
  - Ref: https://developer.mozilla.org/en-US/docs/Glossary/Robots.txt

---

Report what you found to the operator. Do not change the project.
