Staging and Push to Production

A staging copy is a private replica of your live WordPress site. You change and test things there, and only when it works do you send the changes to the live site. Nothing you do on staging touches your live site.

Create a staging copy

1. Open your live app and go to the Staging tab.
2. Press Create Staging and give the copy a name.
3. FlyNode clones the files, plugins, database and settings into a separate container with its own .flynode.io address and its own database. Addresses inside the database are changed to the staging address for you.

You can have one staging copy per site, and a staging copy cannot have a copy of its own. It runs on the same Cloud Workspace, so it shares that workspace's memory and CPU. The "discourage search engines" setting is not carried over to the live site when you push.

Refresh staging from your live site

Staging is a snapshot taken when you created it. If the live site has changed since (new orders, new posts, new comments), open the staging copy's Staging tab and press Refresh from live. It copies the live files and database onto staging, so you start from the latest content. Everything on staging is replaced, so do this before you start new work, not after.

Push to Production

On the staging copy's Staging tab, press Push to Production and choose what goes live. Anything you leave unticked is not touched.

Files

• Themes: replaces the live themes folder.
• Plugins: replaces the live plugins folder.
• Must-use plugins: replaces the live mu-plugins folder. FlyNode's own security plugin is never replaced.
• Media uploads: adds new files; nothing is deleted, and files with the same name are overwritten. Uploads are not backed up.

Database

• Do not change the database: only files are pushed.
• Content only: posts, pages, media records, comments, categories and menus. The live site keeps its users, orders and settings.
• Everything (full database): replaces every table, including users, orders and settings. Orders and comments made on the live site since you made the copy are lost.

A push replaces whole folders and tables. It does not merge. If a plugin was added on the live site after the copy was made, a plugins push removes it. That is why Push to Production first shows what would be removed or replaced on the live site; read it before you confirm.

What happens during a push

1. The live site is backed up first: the database (if it will be replaced) and the themes, plugins and mu-plugins folders that will be replaced.
2. The live site shows a maintenance page for a moment.
3. The chosen parts are copied across, caches are cleared, and the site comes back.

FlyNode keeps the three newest backups of each site.

Undo a push

After a push, the live app's Staging tab shows a Last push from staging card. If the push was a mistake, restore from that card: the live site goes back to how it was before the push (the database and the folders that were backed up). Uploads are not restored, because they are never deleted by a push.

A good routine

1. Refresh staging from live.
2. Make and test your changes on staging (update plugins there first; see Updates, Backups and Rollback).
3. Push only what you changed, and use Content only unless you really need a full database copy.
4. Check the live site, and restore from the Last push card if something is wrong.

On a staging copy the Security tab shows only the Updates card: security settings, scans and automatic updates are managed on the live site.