Identify the application’s runtime, lock files, build commands and required output. Decide which environment values belong at build time and which remain runtime secrets.

1. Start from the intended commit in a clean build environment. Use the supported runtime and install dependencies from reviewed lock files.

2. Run the necessary build and meaningful checks. Include generated assets, runtime dependencies and files the application loads dynamically.

3. Exclude local secrets, unrelated source archives, development databases and temporary logs. Review native dependency compatibility with the target platform.

4. Package the output and record a checksum together with the commit and build identifier. Keep that package immutable after validation.

5. Deploy the same reviewed artifact to the intended release directory and supply runtime configuration through its protected mechanism.

In a clean CI workspace, build the application and generate a small manifest beside the packaged release. Use the real commit and checksum produced by your pipeline. The illustrative values below show the information to retain, not a valid checksum for an existing download.

{
  "release": "example-2026-10-05.1",
  "commit": "REPLACE_WITH_FULL_COMMIT_ID",
  "artifact": "release.tar.gz",
  "sha256": "REPLACE_WITH_COMPUTED_SHA256",
  "build_command": "npm run build",
  "runtime": "PROJECT_APPROVED_NODE_VERSION"
}

Store the archive and manifest together, then deploy that same archive to staging and production after review. Keep runtime secrets outside both files. For native dependencies, record the target platform too, since a Linux package and a laptop build may not be interchangeable.

Expected result: The deployed artifact’s checksum matches the reviewed archive, its commit is traceable, and a clean startup succeeds without files borrowed from the original CI workspace.

Start the artifact in a clean environment without relying on the build workspace. Verify the release identifier and checksum at the destination.

If a file exists only on the developer laptop or CI workspace, add it to the deliberate build process. Copying an extra file manually may fix one deployment but leave the next release broken.

• Deploying repeatable Node dependencies with npm ci
• Building Next.js with the right public environment values
• Deploying with a release directory and a controlled switch
• Protecting production secrets in CI jobs

• GitHub workflow artifacts
• npm ci

• GitHub Actions workflow artifacts