Web Deployment Checklist: From GitHub Actions to DNS, HTTPS, and Core Web Vitals

Overview

Modern web applications often combine source control, a JavaScript build system, a hosting platform, domain records, TLS certificates, environment variables, databases, and third-party services. A change in any one of these areas can affect production. The safest approach is to treat deployment as a sequence of verifiable checkpoints rather than a single button press.

This checklist is designed for teams deploying a frontend, an API, or a Node.js application. Adapt the commands and platform-specific details to your stack, but keep the order: validate the change, build a reproducible artifact, deploy it, verify the public service, and monitor the result.

Keep a short deployment record for each release. Record the commit, deployment time, key configuration changes, migration status, and rollback target. This makes recurring reviews faster and gives the team a shared reference when a problem appears after release.

Before you begin

• Confirm the intended commit or release branch.
• Identify the production environment and its required variables.
• Check whether the release includes database or storage migrations.
• Know the previous healthy version and how to restore it.
• Decide who will verify the deployment and who can approve a rollback.

What to track

1. Source, dependencies, and build output

Start with the change itself. Review the commit history or pull request, confirm that tests cover the affected behavior, and check that the lockfile is committed. A consistent package manager and locked dependency versions help make local, CI, and production installs more comparable. If your team is choosing between npm, pnpm, or Yarn, document the selected tool and use it consistently in local instructions and automation. The comparison of JavaScript project tooling can help structure that decision.

Run the same essential checks in CI that developers are expected to run locally: formatting, linting, unit tests, type checking where applicable, and a production build. Inspect the build output when practical. Unexpectedly large assets, missing files, or a changed output directory can indicate a configuration problem before it reaches users. A CI/CD pipeline checklist is useful for standardizing these gates.

2. Configuration and secrets

List the variables required by the application and distinguish public configuration from secrets. Public browser configuration may be embedded in a client bundle; credentials, signing keys, database URLs, and private API tokens must remain server-side and should be supplied through the hosting environment or a secrets manager.

Verify that production values point to production services. Pay particular attention to API base URLs, allowed origins, cookie settings, storage buckets, email providers, and feature flags. Avoid printing secret values in build logs. If a variable is renamed or removed, treat that as a deployment change that needs explicit review.

3. GitHub Actions and continuous deployment

A GitHub Actions workflow should make the release path visible and repeatable. A basic Node.js deployment workflow might look like this:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  verify-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --runInBand
      - run: npm run build
      - run: ./scripts/deploy.sh

Treat the version in this example as an illustration, not a universal requirement. Match it to the version declared by your project and hosting environment. In a real workflow, the deploy script should authenticate without exposing credentials, publish the expected artifact, and fail clearly if the platform rejects the release.

Consider separating verification from production deployment when the application has a higher operational risk. For example, a pull request can run checks and build the artifact, while a protected branch or manually approved job performs the production release. Whichever model you use, preserve logs and make the deployed commit easy to identify.

4. DNS and HTTPS

DNS connects a domain to the service that should answer for it. Check the records required by your host, then verify the actual records from outside the deployment dashboard. Common records include A or AAAA records for an address, a CNAME for an alias, MX records for mail delivery, and TXT records for verification or email-related configuration. The guide to DNS records provides a practical reference.

Test the root domain and each intended subdomain separately. Confirm that redirects use the preferred hostname, such as redirecting one variant to another rather than serving duplicate versions. Once DNS points to the correct service, open the site over HTTPS and verify that the certificate covers the hostname, pages load without mixed-content warnings, and expected API requests use secure URLs.

5. Application health and rollback

Define a small smoke-test list for every release. It might include loading the homepage, signing in with a test account, submitting a representative form, reading from the API, creating a record in a safe environment, and checking a critical background job. Keep these tests short enough to run immediately after deployment.

A rollback plan should identify the previous artifact, the command or platform action that restores it, and any database changes that cannot be reversed. Application code can often be rolled back quickly; destructive schema changes may require a forward fix instead. Test the rollback process periodically in a non-production environment so it is not theoretical when an incident occurs.

Cadence and checkpoints

Use three review rhythms rather than relying only on release day.

Every deployment

• Confirm the commit, checks, build artifact, and environment variables.
• Review migration status and third-party service changes.
• Run smoke tests against the public URL.
• Inspect application, platform, and deployment logs.
• Record the release and rollback target.

Monthly

Review failed workflow runs, deployment duration, recurring manual steps, dependency updates, expired credentials, DNS changes, and certificate or domain configuration. Check whether the documented deployment process still matches the repository and hosting platform. Remove unused secrets and access paths where appropriate.

Quarterly or after a major change

Run a fuller exercise: deploy a representative change, test rollback, review backup and restore procedures, inspect DNS ownership and account access, and measure performance on important page types. Revisit the CI/CD design when the team adds a service, changes hosting, adopts a new build tool, or separates frontend and backend deployments.

Performance should be tracked as a release signal, not treated as a one-time launch task. Review loading and interaction behavior for key templates, especially after adding JavaScript, images, fonts, analytics, or third-party widgets. Resources on Core Web Vitals, bundle size, image optimization, and lazy loading can support this review.

How to interpret changes

Not every alert means the deployment is broken, and not every successful build means the release is healthy. Interpret signals together.

• Build succeeds, but the page fails: Check runtime logs, missing environment variables, asset paths, server routing, and browser console errors.
• Only some users see errors: Compare hostnames, regions, cached assets, authentication state, feature flags, and rollout percentage.
• DNS works inconsistently: Confirm authoritative records, TTL-related propagation expectations, conflicting records, and whether the hostname is configured at the hosting provider.
• HTTPS works on one hostname but not another: Check certificate coverage, redirects, aliases, and platform domain configuration for each hostname.
• Performance worsens after an otherwise successful release: Compare the changed bundle, images, fonts, server response behavior, and third-party scripts with the previous version.
• Rollback restores the page but not the data: Review migration compatibility and separate reversible application changes from irreversible data operations.

When investigating, compare the current release with the last known healthy release. Change one variable at a time where possible, preserve logs before they rotate, and write down the observed symptom, affected route, timestamp, and suspected change. This turns a vague production complaint into a testable incident.

When to revisit

Revisit this checklist before every production deployment and perform the broader review monthly or quarterly, depending on how often the application changes. Update it immediately when the team changes hosting, DNS providers, package managers, build commands, authentication, database structure, certificate management, or release approvals.

Use the following practical routine for the next release:

1. Open an issue or release note using this checklist.
2. Attach the commit, workflow run, build result, and migration plan.
3. Verify DNS, HTTPS, environment variables, and smoke-test routes.
4. Deploy through the documented GitHub Actions path or equivalent CI/CD process.
5. Monitor logs and key performance signals after release.
6. Keep the deployment if behavior is healthy; otherwise restore the known-good version or apply the documented forward fix.
7. Close the review by recording what changed in the process itself.

A deployment checklist becomes more valuable when it changes with the system. Keep it close to the code, assign ownership for periodic review, and use each release to remove uncertainty from the next one.