Set Up a Staging Environment Before Updating Your Live Website

Audit What Must Stay Separate From Production

Before creating staging, identify which parts of the project must stay separate from production. Your staging environment should behave like the live project without accidentally modifying real users, real payments, or production data.

Staging Environment Readiness Audit

Reports the framework, package manager, production build/start commands, output directory, required Node.js version, every environment-variable name, and every production dependency — databases, auth, storage, payments, email, AI/external APIs, webhooks, analytics, scheduled jobs, OAuth, CORS — then classifies each as shareable, needing separate staging credentials, or never safe to reuse from staging, without exposing secret values or changing anything, and finishes with a recommended staging architecture.

Review this project specifically for creating a separate staging environment before future production updates. Identify: - the framework and project type - the package manager - the production build command - the start command, if required - the build output directory - the required Node.js/runtime version - every environment variable used by the project — names only - the production database - authentication - storage and file uploads - payments - email - AI or external APIs - webhooks - analytics - scheduled/background jobs - OAuth providers - CORS or allowed origins - anything that depends on the production domain Then classify each dependency into: 1. Can be shared safely between staging and production 2. Should use separate staging credentials or configuration 3. Must never use the production resource from staging Pay particular attention to: - production databases and user data - payment providers - outgoing emails or SMS - webhooks - file uploads - analytics - scheduled jobs - destructive/admin operations Do not expose secret values. Do not change or deploy anything yet. Finish with: Recommended staging architecture Include: - staging deployment type - suggested staging URL - Git branch strategy - which services can remain shared - which services should be separate - required staging environment-variable names - anything that must be changed before staging is safe

Define Your Staging and Production URLs

Create a configuration that clearly separates staging from production.

A common setup is: Production — example.com Staging — staging.example.com The staging site should use its own environment values where necessary.

Prepare the Project for Staging

Use environment variables or existing configuration patterns to distinguish between staging and production.

Do not duplicate the entire codebase just to create staging.

Staging Configuration Preparation

Prepares one shared codebase to support staging alongside production — separate environment variables, no hard-coded staging URLs, no exposed credentials, and staging configuration for the URL, API, database, auth, OAuth callbacks, CORS, storage, email, payments, webhooks and external APIs — makes sure staging can never accidentally trigger real production actions, and returns READY or NOT READY.

Prepare this project to support a staging deployment alongside production. Use the audit you just completed. Make the smallest necessary changes. Requirements: - keep one shared codebase - preserve the existing production behavior - allow staging and production to use different environment variables - do not hard-code staging URLs into production code - do not expose private credentials Where relevant, prepare separate staging configuration for: - site/app URL - API URL - database connection - authentication URLs - OAuth callbacks - allowed origins/CORS - storage - email - payments - webhooks - analytics - external APIs If the application performs actions that could affect real users or money, make sure staging cannot accidentally trigger those production actions. Do not create a second application architecture unless required. Do not deploy anything yet. Finish with: Staging configuration: READY / NOT READY If READY, list: - required staging environment-variable names - any separate staging services/accounts needed - anything that must be configured after the staging URL exists If NOT READY, list exactly what remains.

Create a Staging Branch

Create staging as a separate deployment, not as a replacement for the live site.

On Hostinger, a subdomain can be created as an independent website, which makes a setup such as staging.example.com suitable for a separately managed staging deployment.

If the project uses GitHub, use a separate branch such as staging. Keep your normal production branch, such as main, for the live deployment.

A simple workflow is: feature/change → staging → main The exact branch names can follow the repository's existing conventions.

Set Up the Staging Site

Create a separate website or web app for the staging deployment, for example staging.example.com.

Connect it to the repository and configure it with the staging branch, not the production branch. Hostinger's Node.js/Web App flow supports GitHub-connected deployments with configurable build settings and automatic redeployment from the connected repository.

Websites Add Website Deploy Web App

Connect the repository Set the staging branch, not the production branch Add the staging environment variables identified earlier

IMPORTANT

Do not copy production secrets blindly.

Staging Deployment Configuration Review

Verifies the staging deployment's repository, branch, runtime, build/start commands, environment variables, database, authentication, CORS, payment, email and webhook configuration — confirms it cannot overwrite production, use dangerous production resources, or expose production secrets, and that the production domain is unchanged — without deploying automatically — then returns READY or NOT READY.

Review the staging deployment configuration before I launch it. Verify: - the correct Git repository - the staging branch - framework/project type - Node.js/runtime version - build command - start command, if required - output directory or server entry point - staging environment-variable names - staging database configuration - authentication URLs - CORS/allowed origins - payment configuration - email configuration - webhook configuration Check specifically that: - this deployment cannot overwrite the production deployment - staging does not accidentally use dangerous production resources - production secrets have not been exposed - the production domain is unchanged Do not deploy automatically. Finish with: Staging deployment: READY / NOT READY If NOT READY, list only what must be fixed.

IMPORTANT

Deploy the staging version only after this check passes.

Test the Staging Environment

Once staging is live, use it as the place where changes are verified before production. Check the same important flows your real users depend on. This may include:

Pages and navigation

Responsive/mobile layout

Authentication

Protected pages

Database reads and writes

API requests

File uploads

Forms

Email

Payments in test mode

Webhooks

AI features

Redirects

Browser console errors

Failed network requests

IMPORTANT

If staging uses test users or test data, confirm that production users and records are unaffected.

Staging Release Verification

Compares the staging deployment against production and the intended release — build success, changed and existing features, authentication, protected areas, database isolation, uploads, email, payments in test mode, webhooks, external APIs, CORS, and browser/runtime errors — confirms no production-only secret was exposed and nothing touches production — without modifying or merging to production — then returns PASS or NOT READY.

Review this staging deployment before I promote the changes to production. Compare it with the current production application and the changes I intend to release. Verify: - the production build succeeds - changed pages/features work - existing important features still work - authentication works - protected areas remain protected - database operations use the intended staging environment - staging cannot modify protected production data unexpectedly - uploads/storage work - email behavior is safe for staging - payments use test/sandbox mode when appropriate - webhooks use the intended staging endpoints - external APIs work - CORS and allowed origins are correct - there are no important browser, network, or runtime errors - no production-only secret or credential has been exposed Do not modify production. Do not merge or deploy to the production branch. Finish with: Staging status: PASS / NOT READY If NOT READY, list exactly what must be fixed before production.

IMPORTANT

Do not promote a release simply because the staging homepage loads. Test the actual functionality affected by the update.

Check What Production Needs Before Publishing

Once staging passes, move the tested code into the production branch using your normal Git workflow. The goal is for production to receive the same version you just tested, rather than making additional untested edits during release.

Check whether the release requires any production-side changes, such as:

New environment variables

Database migrations

Authentication configuration

New OAuth callbacks

CORS changes

Storage changes

Webhook updates

Payment configuration

Scheduled jobs

Production domain changes

Production Promotion Readiness Check

Diffs the tested staging release against current production — build status, environment variables, database migrations, authentication, API compatibility, CORS, storage, email, payments, webhooks, and external service or scheduled-job changes — identifies what must be completed before or right after deployment, without merging, pushing, or deploying anything automatically — then returns YES or NO on production readiness.

The staging version has passed testing and I want to promote the same release to production. Review the difference between the current production version and the tested staging version. Check: - whether the exact tested changes are ready to merge - production build status - new or changed environment variables - database migrations - authentication changes - API compatibility - CORS or allowed-origin changes - storage changes - email changes - payment or webhook changes - external service configuration - scheduled/background job changes Identify anything that must be completed in production before or immediately after deployment. Do not merge, push, or deploy anything automatically. Finish with: Ready for production: YES / NO If NO, list exactly what remains.

Publish the Tested Release

When the check returns YES:

Merge or promote the tested changes into the production branch Let the production deployment run Do not modify the staging environment during the production release Test the live website immediately after deployment

Run the Final Production Check

The tested staging release has now been deployed to production. Run a focused post-deployment verification.

Post-Deployment Production Verification

Confirms the deployed release matches the tested version, and that pages, authentication, APIs, database operations, storage, email, payments and webhooks all work — checks that no staging URL or configuration leaked into production and no production traffic reaches staging services — without making additional feature changes — then returns GOOD or ROLLBACK NEEDED with the safest immediate rollback path if something failed.

The tested staging release has now been deployed to production. Run a focused post-deployment verification. Check: - the live production version matches the tested release - important pages load - authentication works - APIs and database operations work - storage/uploads work - email works - payments and webhooks work if affected - production environment variables are correct - no staging URL or staging configuration leaked into production - no production traffic is being sent to staging services - no important browser, network, or runtime errors appeared after deployment Do not make additional feature changes. Finish with: Release status: GOOD / ROLLBACK NEEDED If ROLLBACK NEEDED, identify the safest immediate rollback path using the repository and deployment history.

After staging is configured, use it for future meaningful updates:

Make changes → deploy to staging → test → promote the tested version → verify production

You do not need to create a new staging environment for every update. Keep the staging deployment available and reuse it for future releases.