A website deployment should not feel like a risky final step. It should be a repeatable process that lets you test, review, approve, and release changes with fewer surprises. This is the main reason teams use a staging-to-production workflow.
In this setup, staging acts as a safe testing space, while production is the live website users see. Developers can push code to staging first, run checks, fix issues, and then move only approved changes to production.
Deploying directly to production can introduce avoidable risks, especially when configuration changes, dependency updates, or database migrations are involved. Even small updates can break layouts, APIs, authentication flows, or caching behavior if they are not tested in an environment that closely mirrors production.
A staging-to-production workflow reduces these risks by introducing a controlled review process before deployment. Instead of pushing changes directly to the live site, teams can validate updates in staging, verify dependencies, review logs, and confirm that critical user flows still work as expected.
This tutorial will walk you through a practical workflow using a version control system (VCS), separate environment files, deployment commands, backups, and rollback steps.
1. Set Up Separate Staging and Production Environments
The first step is to keep staging and production separate. They can live on the same hosting account, but they should not share the same folder, database, or environment settings.
One common deployment problem is “environment drift”, where staging and production behave differently due to mismatched configurations such as PHP versions, missing extensions, or cache differences. This is widely referred to as configuration inconsistency in modern DevOps practices, often discussed under the concept of Continuous Delivery principles.
Keeping environments as similar as possible ensures that what works in staging behaves the same in production, reducing unexpected failures during deployment.
A simple folder structure may look like this:
/home/user/sites/example.com/production
/home/user/sites/example.com/staging
The production folder serves the live domain:
example.com
The staging folder can use a subdomain:
staging.example.com
This keeps test changes away from users and gives your team a place to check layouts, forms, redirects, plugins, database changes, and performance before release.
1.1 Create Matching Folder Structures
Try to keep both environments as similar as possible.
production/
public/
logs/
backups/
.env
staging/
public/
logs/
backups/
.env
Environment parity reduces deployment risk because issues caused by infrastructure differences become easier to detect early in staging rather than in production.
2. Connect the Project to Git
Git gives your deployment process structure. It lets you track code changes, review updates, and move work between environments with less guesswork.
Version control also provides traceability, allowing teams to identify exactly which change introduced a bug or regression in production. The official Pro Git book explains these concepts in depth.
Inside your local project folder:
git init
git add .
git commit -m «Initial project setup»
Then add your remote repository:
git remote add origin git@your-repo-url:project/site.git
git push -u origin main
For a basic deployment workflow, use two main branches:
staging
main
The staging branch is where new work is tested. The main branch is used for production-ready code.
2.1 Use Separate Branches for Staging and Production
A simple branch flow:
feature branch → staging branch → main branch → production
This branching strategy introduces a controlled promotion flow where only validated changes move toward production.
For example,
git checkout -b feature/contact-form-update
Then merge into staging:
git checkout staging
git merge feature/contact-form-update
git push origin staging
Then promote to production:
git checkout main
git merge staging
git push origin main
This structure makes debugging easier because each environment represents a known state of the application lifecycle.
3. Configure Environment Variables Safely
Staging and production often use different API keys, database credentials, cache settings, debug modes, and email services.
Environment variables separate configuration from application code, making deployments more secure and flexible.
.env files:
.env.staging
.env.production
Example:
APP_ENV=staging
APP_DEBUG=true
DB_NAME=example_staging
APP_ENV=production
APP_DEBUG=false
DB_NAME=example_production
Sensitive files should never be committed to version control. Instead, use .env.example as a safe reference template.
4. Deploy Changes to Staging First
SSH into server:
ssh user@server-ip
Move to staging:
cd /home/user/sites/example.com/staging/public
Clone t branch:
git clone -b staging git@your-repo-url:project/site.git .
Pull updates
git pull origin staging
If the project uses Node.js, install dependencies and build assets:
npm install
npm run build
If the project uses PHP with Composer, run:
composer install —no-dev —optimize-autoloader
4.1 Run Basic Pre-Launch Checks
curl -I https://staging.example.com
HTTP checks help identify server misconfigurations, failed application boots, or redirect issues immediately after deployment.
Check links:
npx broken-link-checker https://staging.example.com
Logs:
tail -n 50 /home/user/sites/example.com/staging/logs/error.log
Logs often reveal runtime issues that are not visible during build or local testing phases.
5. Move Approved Changes to Production
git checkout main
git merge staging
git push origin main
SSH:
ssh user@server-ip
cd /home/user/sites/example.com/production/public
git pull origin main
Production deployments should ideally follow a verified staging approval cycle to minimize risk of downtime or broken user flows. This aligns with safe deployment practices commonly used in modern systems based on Continuous Delivery principles.
Install production dependencies:
npm ci —omit=dev
npm run build
5.1 Be Careful With Database Migrations
Database migrations are one of the highest-risk parts of deployment because they can directly affect live user data.
Before running migrations:
ensure backups exist
test in staging
verify rollback steps
avoid destructive changes during peak traffic
Backward-compatible migrations help reduce downtime by allowing old and new versions of the application to run during deployment.
6. Add Backups, Rollbacks, and Monitoring
A good deployment workflow always includes a safety net. Before production deployment, create a backup of the current files and database.
Create backup:
tar -czf backup.tar.gz production/
Database:
mysqldump -u db_user -p example_production > backup.sql
Rollback:
git reset —hard previous_commit_hash
Rollback procedures should be tested regularly to ensure they work under real failure conditions.
Note: Rolling back application code does not always reverse database changes, so database restoration may also be required depending on the deployment.
7. Scale the Workflow Across Multiple Sites
Consistency becomes even more important when managing deployments across multiple client websites. Without standardized workflows, teams can quickly run into issues such as inconsistent environments, missed backups, or unclear rollback processes.
As deployment workflows grow across multiple projects, it helps to centralize staging, monitoring, and maintenance tasks so operations remain predictable across environments.
For teams managing multiple client websites, solutions like web hosting for agencies can help streamline staging environments, deployment workflows, and site management across different projects.
To keep the process consistent, use a deployment checklist:
Pull the latest staging branch
Install dependencies
Build assets
Test staging URL
Check logs
Back up production files
Back up production database
Merge staging into main
Deploy to production
Clear cache
Verify live site
Conclusion
A staging-to-production workflow gives structure and predictability to deployments.
Instead of focusing on speed alone, reliable deployment systems prioritize consistency, rollback safety, and environment parity.
Even a simple workflow can significantly reduce production risks when applied consistently across projects.
Over time, teams can further improve this process through automation, CI/CD pipelines, and standardized deployment scripts.