---
title: Staging Environment Workflow
type: concept
created: '2026-01-29'
updated: '2026-01-29'
source_docs:
- raw/2026-01-29-team-stand-up-118147644.md
tags:
- wordpress
- wp-engine
- staging
- devops
- protocols
layer: 2
client_source: null
industry_context: null
transferable: true
---

# Staging Environment Workflow

## Overview

All WordPress development must follow a **spin up → develop → push → delete** cycle for staging environments. Persistent staging environments are a liability: they consume server resources, drift out of sync with production, and create risk when pushed.

The goal is to always have exactly one active environment per site — production — and to treat staging as a temporary, disposable workspace.

## The Standard Process

1. **Spin up** a fresh staging environment copied directly from the current production site
2. **Develop** — make all changes in staging, never directly in production
3. **Push** the completed work from staging to production
4. **Delete** the staging environment immediately after the push

Repeat this cycle for every discrete piece of work. Do not leave staging environments running between tasks.

## Why This Matters

### Prevents Stale Code Pushes

A staging environment that was created weeks ago is no longer a true copy of production. Pushing stale staging to production will overwrite recent changes and introduce regressions. Creating a fresh copy at the start of each task eliminates this risk entirely.

### Automatic URL Rewriting

WP Engine automatically rewrites URLs when pushing from staging to production — `staging.example.com` becomes `example.com`, and `http://` becomes `https://`. This only works correctly when using the native push workflow. Manual search-and-replace operations on the database are error-prone and should be avoided.

### Server Resource Management

Every environment is a full copy of the site. Two persistent environments means double the storage; three means triple. Across ~40 managed sites, orphaned staging and dev environments add up to significant unnecessary load. Deleting staging after each use keeps the footprint minimal.

### Reduces Coordination Complexity

Because the team is distributed across time zones, verbal coordination about who is using which environment is unreliable. The push-and-delete model means there is never ambiguity: if a staging environment exists, someone is actively using it right now.

## Tracking Active Staging Environments

Because developers work asynchronously, a shared tracking mechanism is required so team members don't accidentally overwrite each other's work. The recommended approach is a simple shared sheet (Google Sheet or equivalent) with:

- Site name
- Who is working in staging
- Date started
- Status (in progress / ready to push / deleted)

This sheet must be kept current. An outdated entry is worse than no entry — it destroys confidence in the whole system. Developers should update the record when they spin up and again when they delete.

> **Owner:** Isalia is responsible for developing and maintaining this tracking process.

## Local Development

Developers may build on a local WordPress environment (e.g., Local by Flywheel) for speed. When local work is ready, the recommended path is:

1. Push from local machine to a fresh staging environment (via Bitbucket or equivalent)
2. Verify the work on staging against the live internet environment
3. Push from staging to production
4. Delete staging

Avoid uploading compressed file archives manually — this bypasses URL rewriting and version tracking.

## What Not to Do

| Anti-pattern | Problem |
|---|---|
| Leaving staging environments running indefinitely | Wastes resources; environment drifts from production |
| Pushing from a staging environment that wasn't freshly copied | Overwrites recent production changes |
| Manually doing search-and-replace on URLs after a push | Error-prone; WP Engine handles this automatically in the push workflow |
| Working directly in production | No safety net; breaks are immediately live |

## Related

- [[wiki/knowledge/wordpress/plugin-management-protocols]]
- [[wiki/knowledge/wordpress/wp-engine-caching-configuration]]
- [[wiki/knowledge/wordpress/backup-restore-policy]]
- [[wiki/meetings/2026-01-29-team-stand-up]]