Web App Deployment Checklist: From Production Readiness to Ongoing Maintenance

Overview

Deploying a web app is more than uploading a build. A reliable release connects application code to infrastructure, data, external services, DNS, monitoring, and a recovery plan. The exact commands vary by app development platform and hosting environment, but the decisions that prevent avoidable incidents are broadly consistent.

Work through this checklist before a first production launch and again before major releases. Mark each item as complete, not applicable, or blocked. If an item is blocked, record the owner and the condition required to resolve it. This turns a deployment from a sequence of informal tasks into a repeatable part of your CI/CD for app development workflow.

For broader planning, compare this guide with how to design app environments for development, staging, and production. Separating environments and documenting their differences makes the checks below easier to perform.

Checklist by scenario

Before the first production deployment

• Confirm the production architecture: frontend hosting, backend runtime, database, file storage, queues, caches, and third-party integrations.
• Document which services are required for the app to start and which are optional. Define what the application should do if an optional dependency is unavailable.
• Create a production configuration inventory. Include runtime settings, allowed origins, callback URLs, email settings, storage locations, feature flags, and external API endpoints.
• Store secrets in an approved secret manager or protected CI/CD variables. Do not commit credentials, private keys, database passwords, or tokens to the repository.
• Use separate credentials for development, staging, and production. Limit each credential to the permissions its service requires.
• Define a database migration process. Test migrations against a production-like copy or representative dataset, and document whether each migration is backward compatible.
• Set the production build to use the intended dependency lockfile, runtime version, environment mode, and asset configuration.
• Run automated tests, linting, type checks, and a production build in CI. Treat failures as release blockers unless an explicit exception is documented.
• Verify that error pages, authentication flows, forms, file uploads, background jobs, and payment or messaging integrations behave correctly in staging.
• Choose a deployment method and record its rollback behavior. Options may include a rolling release, blue-green deployment, versioned artifact, or platform-managed revision.

For a routine application release

• Review the change list and identify database, API, authentication, infrastructure, and configuration changes separately.
• Confirm that the artifact deployed to production was built from the intended commit and that the build is reproducible.
• Check whether migrations must run before, during, or after application startup. Avoid making a new application depend on a schema that older instances cannot read during a rolling release.
• Confirm feature flags and staged functionality have an owner and an expiry or review date.
• Verify that the release window has appropriate technical coverage and that the rollback decision-maker is known.
• Run smoke tests immediately after deployment: load the homepage, authenticate, exercise a core transaction, submit a representative form, and verify a key API response.
• Watch logs, error rates, latency, resource use, queue depth, and database health during the initial observation period.

For a high-risk change

• Use a smaller rollout, internal audience, canary, or maintenance window when the platform supports it.
• Capture a database backup or confirm the provider's recovery point before destructive schema or data changes.
• Test rate limits, authorization boundaries, webhook retries, idempotency, and failure handling for affected integrations.
• Prepare a written rollback or forward-fix plan before deployment. A database rollback may not be safe simply because an application rollback is available.
• Notify relevant support, operations, and product stakeholders about expected behavior, monitoring signals, and escalation contacts.

For a deeper release sequence, see the complete CI/CD pipeline for web and mobile apps and the guide to an app release rollback plan.

What to double-check

Environment and secrets

Compare the documented configuration with the deployed configuration rather than assuming they match. Check URLs, ports, origins, cookie settings, encryption keys, time zones, storage permissions, and service account scopes. Make sure secrets are available to the runtime but are not printed in build output, logs, error messages, or diagnostic pages. Rotate credentials when access changes and remove unused variables from the deployment configuration.

Database and data

Confirm that backups exist, retention is understood, and restoration has been tested at a level appropriate for the application. Review migration duration, locking behavior, indexes, constraints, and data transformations. If a migration can take longer than the deployment window, split it into compatible phases: add the new structure, deploy code that can use both versions, migrate data, then remove the old structure later.

Builds and dependencies

Check that production assets do not contain development endpoints, test credentials, source maps with unintended exposure, or debugging controls. Pin or otherwise control dependency versions, review changes to critical packages, and confirm the runtime version is supported by the application and its build tools. A small online developer utility such as a SQL formatter or regex tester can help inspect generated queries and validation rules, but it should not replace automated tests or code review.

Observability and security

Verify structured logs, request identifiers, health checks, uptime monitoring, and actionable alerts. Alerts should identify a condition that requires attention rather than simply reporting normal traffic variation. Confirm that sensitive fields are redacted. Test authentication, authorization, session expiry, transport security, input validation, upload restrictions, dependency scanning, and administrative access. Record who can deploy, who can change production settings, and how access is reviewed.

Domain, performance, and recovery

Check DNS records, TLS certificates, canonical host behavior, redirect rules, caching, compression, robots directives, and any content delivery configuration. Test the app from a clean session and on a representative mobile connection. Verify that static assets use cache-busting or versioned names. Finally, confirm that the team can identify the previous release, stop or reverse the rollout, restore data when necessary, and communicate the result.

Common mistakes

• Deploying directly from a laptop. Manual local deployments make the artifact, configuration, and operator difficult to reproduce. Prefer a reviewed commit and a recorded CI/CD job.
• Treating staging as proof of production readiness. Staging may use different data volume, permissions, domains, integrations, or traffic. Document those differences and test the risks they create.
• Running migrations without a compatibility plan. Rolling deployments can temporarily run multiple application versions. Design schema changes for that overlap.
• Keeping one emergency rollback path. An application rollback may fail after an irreversible data change. Maintain backups, forward-fix procedures, and a clear decision tree.
• Monitoring only uptime. A server can respond successfully while sign-ins, background jobs, payments, or key API calls fail. Monitor user-critical transactions as well as infrastructure.
• Logging too much sensitive data. Debugging convenience can expose tokens, personal information, or request bodies. Define redaction rules before an incident occurs.
• Leaving temporary flags and access in place. Temporary configuration becomes permanent when it has no owner or review date. Add removal tasks to the release record.

Teams choosing app deployment tools should evaluate these operational details, not only build speed or hosting convenience. The app development platform evaluation framework can help organize that decision.

When to revisit

Revisit this checklist before every production release, with a shorter smoke-test version for low-risk changes and a fuller review for infrastructure, database, authentication, or integration changes. Perform a broader review before seasonal planning cycles, traffic-sensitive launches, major product milestones, or changes to the team responsible for operations.

Update the checklist whenever the workflow or tools change: a new hosting provider, CI/CD runner, database, frontend framework, identity service, deployment strategy, or secret-management process can invalidate old assumptions. Also revise it after an incident, failed rollback, security finding, unexpected performance issue, or recovery exercise.

To keep it useful, assign an owner, add a last-reviewed date, link each step to the relevant runbook, and remove checks that no longer represent real risk. Start your next release by copying the current version, recording exceptions, and scheduling a post-release review. For day-to-day debugging and inspection, the developer utilities toolkit provides additional workflow ideas, while the related repeatable web app CI/CD workflow can help turn this checklist into an automated process.