Staging Environments

A staging environment is a complete copy of your live website running at staging.your-domain.com. You can update WordPress plugins, change the theme, edit code, run database migrations — all without touching the version your real visitors see. When you're ready, you push the changes to production.

Setting this up manually takes 30+ minutes (create subdomain, copy files via rsync, dump database, import database, edit wp-config.php, search-replace URLs). Opterius does it in one click.

What Gets Cloned#

When you click Create Staging, Opterius automatically:

1. Creates a subdomain at staging.your-domain.com with its own document root, Nginx vhost, and PHP-FPM pool
2. Creates a fresh database named {user}_db_staging with its own user and password
3. Copies all files from production to staging using rsync (excluding cache directories, node_modules, and .git for speed)
4. Clones the production database into the new staging database
5. Patches wp-config.php (if WordPress) — replaces DB_NAME, DB_USER, DB_PASSWORD with the new staging credentials
6. Patches .env (if Laravel) — replaces DB_DATABASE, DB_USERNAME, DB_PASSWORD, and APP_URL, then runs php artisan config:clear
7. Runs wp search-replace (if wp-cli is installed) — swaps https://your-domain.com for https://staging.your-domain.com throughout the database

The whole process takes about as long as your rsync and mysqldump would take if run manually — typically 30 seconds to 5 minutes depending on site size.

Creating a Staging Environment#

1. Open Staging in the sidebar.
2. Find the production domain you want to clone in the list.
3. Click Create Staging.
4. Wait for the page to reload — you'll see the new staging.your-domain.com link appear in green.
5. Click the link to visit your staging copy.

That's it. You now have a complete, working copy of your site.

Working in Staging#

The staging copy is completely isolated from production:

• Different files (separate public_html)
• Different database (separate MySQL DB and user)
• Different Nginx vhost and PHP-FPM pool
• Different SSL certificate (auto-issued for the subdomain)

You can:

• Update WordPress core, plugins, and themes — risky changes won't break the live site
• Edit theme files, custom code, configuration
• Run database migrations or schema changes
• Test new features end-to-end
• Demonstrate work to a client before pushing it live

Visitors to your live site will not see any of your staging changes.

Deleting a Staging Environment#

When you're done with staging, click the Delete button next to it on the Staging page. This:

• Removes the staging subdomain (vhost, FPM pool)
• Deletes the staging document root and all files inside it
• Deletes the staging database and user
• Removes the staging subdomain from DNS

The production site is completely unaffected.

Limitations and Caveats#

One staging clone per domain#

You can only have one staging environment per production domain. If you need a second copy, delete the first one and create a new one. This is a deliberate constraint to keep things simple — most teams only need one at a time.

Manual push-to-production#

Opterius creates the staging environment for you, but does not yet push staging changes back to production. When you're ready to go live with your changes, you need to manually copy them across:

• For files: use rsync from the staging document root to the production document root via SSH
• For database: use mysqldump from the staging database to the production database, then re-run wp search-replace to swap URLs back

A future release will add a one-click "Push to Production" button.

WordPress URL rewriting needs wp-cli#

For WordPress sites, the production URL is stored in dozens of places inside the database — not just wp-config.php. To swap your-domain.com for staging.your-domain.com throughout the DB content, Opterius runs wp search-replace automatically.

If wp-cli is not installed on the server, this step is silently skipped. The site will load on the staging URL but might still output some links pointing to the production domain. To install wp-cli:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp

After installing, delete and re-create the staging environment to get the URL rewrite.

Other CMS / framework support#

Out of the box, Opterius patches:

• WordPress: wp-config.php DB credentials + wp-cli search-replace for the database
• Laravel: .env DB credentials and APP_URL + clears the config cache

For other applications (Joomla, Drupal, custom PHP), you'll need to manually edit the staging copy's configuration files to point to the new database. The files are at /home/{user}/staging.your-domain.com/public_html/.

Multiple databases#

If your account has multiple databases attached, Opterius only clones the first one as the staging database. If your site uses multiple databases (e.g. one for WordPress core and one for an application), you'll need to clone the additional databases manually after creating the staging environment.

Backups exclude cache#

The rsync clone uses --exclude rules for common cache directories (/cache, /wp-content/cache, /storage/logs, /storage/framework/cache, /node_modules, /.git). This keeps the clone fast and avoids copying transient junk. If you have a non-standard cache directory, it will be copied.

Troubleshooting#

"A staging environment already exists for this domain." You can only have one. Delete the existing one first, then create a new one.

Files copied but the site shows "Error establishing a database connection." The WordPress URL replacement worked but the wp-config.php patch failed. SSH in and check that the DB_NAME, DB_USER, and DB_PASSWORD constants in /home/{user}/staging.your-domain.com/public_html/wp-config.php match the staging database credentials shown in the panel.

The staging URL loads but shows the production domain everywhere. wp-cli isn't installed on the server. Install it (instructions above) and re-create the staging environment.

The staging site gets errors about cache or compiled views. Some frameworks cache compiled templates and config files inside the document root. For Laravel, run php artisan config:clear && php artisan cache:clear && php artisan view:clear from the staging document root via SSH. For other frameworks, manually delete the cache directory.

SSL certificate warning on staging URL. SSL certificates for staging subdomains take a few minutes to issue automatically. If after 5 minutes you still see a warning, go to the SSL page and manually re-issue the certificate for the staging subdomain.