Staging environments

The Staging tab on your site detail page lets you create a separate copy of your site at staging.<your-domain>. v1 covers the create / delete / open lifecycle; pushing changes from staging back to live is a manual procedure described below. Automated Push to Live ships in v1.5.

Creating a staging environment

Open your site's detail page → Staging tab → Create Staging Copy. The dashboard registers a staging entry at staging.<your-domain> and you'll see the new buttons (Push to Live, Open Staging, Delete Staging).

You'll need a DNS record (A or CNAME) for the staging subdomain pointing at your CloudMagnus server IP before the staging URL resolves from your browser. The same IP shown on your site detail page works for the staging subdomain.

Pushing staging back to live (v1 manual procedure)

Until v1.5 wires this into the Push to Live button, the supported way to promote staging changes is via SFTP and mysqldump. The procedure below is what the v1.5 button will eventually automate; running it by hand gives you the same result with a few more steps.

1. Snapshot live first (rollback insurance)

Open the Backups tab on your live site → Create Manual Backup. Wait for the row to flip to completed. If the push goes wrong, restore from this snapshot.

2. Copy the staging files into live

Two SFTP sessions, one to each siteUser. The simplest reliable path is to dump the staging files to a tarball on the staging side, copy it down to your laptop, then push it up to live and extract it:

# on your laptop:
sftp [email protected]
sftp> cd htdocs
sftp> get -r .  staging-files/
sftp> bye

# tar it locally so you push one file, not thousands:
tar czf staging-files.tar.gz staging-files

sftp [email protected]
sftp> put staging-files.tar.gz tmp/staging-files.tar.gz
sftp> bye

# on the live server (SSH in, the SSH login is the same as SFTP):
ssh [email protected]
cd ~/htdocs
# OPTIONAL: clear the live tree first if you want a strict mirror.
# Be sure your snapshot from step 1 is "completed" before doing this.
rm -rf .[!.]* *
tar xzf ~/tmp/staging-files.tar.gz --strip-components=1
exit

If your tree is small enough that you'd rather skip the tar dance, scp -r straight from staging to live works too — but a tarball is faster on slow links and avoids partial-copy states.

3. Dump the staging database

ssh [email protected]
mysqldump -u <staging_db_user> -p <staging_db_name> > ~/tmp/staging-db.sql
exit

4. Move the dump over to live and import it

# pull the dump down to your laptop, push it up to live:
sftp [email protected]
sftp> get tmp/staging-db.sql
sftp> bye

sftp [email protected]
sftp> put staging-db.sql tmp/staging-db.sql
sftp> bye

# import:
ssh [email protected]
mysql -u <live_db_user> -p <live_db_name> < ~/tmp/staging-db.sql
exit

5. Rewrite domain references inside the database

The database you just imported still references staging.<your-domain> in places. Each framework has its own way of fixing this:

  • WordPress: wp search-replace 'staging.example.com' 'example.com' --all-tables (run inside ~/htdocs after SSH in; WP-CLI ships with the WordPress scaffold).
  • Laravel: the URL lives in ~/htdocs/.env as APP_URL; staging's .env shouldn't have overwritten live's because .env isn't typically tracked, but verify.
  • Django: ALLOWED_HOSTS in settings.py, plus any Site objects in the django.contrib.sites table — UPDATE django_site SET domain='example.com' WHERE domain='staging.example.com';

6. Smoke-test the live site

Visit the live URL in a fresh browser session (incognito to avoid stale cookies). If anything looks wrong, the Backups tab → Restore on the snapshot you took in step 1 will roll back files and database in one step.

Deleting staging

The Delete Staging button removes the dashboard's staging entry. v1 doesn't yet de-provision the underlying staging siteUser — file an operator request via support if you want the actual files and database removed too.

Why isn't this automated yet?

A safe automated push-to-live needs a pre-push backup, atomic file swap with rollback, framework-aware database import that rewrites the site URL, and an idempotent "you already pushed this exact staging snapshot" check. Each of those pieces is its own design decision; we'd rather ship the manual procedure documented honestly in v1 than ship a button that occasionally takes a customer site offline. v1.5 wires the same workflow into one click.