Copy staging into live

Copy into live puts the database tables and uploads of staging, or of a multidev, onto your live site. Use it when the content you built on staging should go live, such as new pages, products, or media. Code never moves this way: plugins, themes, and other code reach live through a promote.

This changes the site your visitors use, so it asks for more than a normal copy. It takes a restore point of live first, and it does not start until you have typed live's address.

Where to find it

Open Manage environments and use the menu on the Live row: Copy staging or a multidev into live. On live's Info page it is also in the Push environment menu. You see it only if your role may promote and restore live: Owners, Admins, Developers, and the Site Admins and Site Developers of this site.

Step one: choose what to copy

1. Copy from. A running staging or multidev environment of this site, on the same server as live.
2. Tables. No tables is selected at first. Choose Every table or Some tables and tick the ones you want. The list shows each table's size.
3. Uploads. No uploads is selected at first. Choose All uploads or Some folders. Uploads are added to live's: new files and newer files arrive, files that only live has are kept, and a newer live file stays unless you tick Replace files that differ on live.

Nothing is chosen for you. Continue stays off until you pick at least one table or one uploads folder.

Step two: read the warning and confirm

The next step has a red border. It says:

• This replaces the selected tables on live with the ones from the source.
• Orders, users, comments, and form entries created on live since the source was last refreshed are overwritten.
• If live runs WooCommerce, do not copy the database while live takes orders, unless you mean to replace them.
• Live may be briefly slow while the copy runs.
• Avaloi takes a restore point of live first, keeps it 14 days, and you restore it from Backups on live.

It also shows how many tables and how much data it will replace, and how many tables live keeps because the source does not have them. To go on, tick I understand that live's data is replaced, type live's address (or the site name) exactly, and press Copy into live. The button stays off until both are right.

What stays as it is on live

• Tables the source lacks. A copy replaces only the tables you chose. Other tables on live stay.
• Search engine visibility. Staging hides itself from search engines and live does not. Live keeps its own setting.
• Avaloi settings. Mail relay, cache and edge settings, password protection, and login settings stay.
• User roles. Live keeps its own role definitions.
• Keys and salts. They live in wp-config.php, which a copy never touches.
• Tables that belong to Avaloi. They never move.

In the copied tables, Avaloi replaces the source's address with live's main address, so links keep working. On a Multisite network, each subsite keeps live's host.

While it runs and after

Avaloi works in this order, and each step is its own job on the Jobs tab:

1. It takes the restore point of live. If that fails, nothing on live changes and the copy does not start.
2. It copies the tables and the uploads.
3. It clears live's caches and the edge cache.
4. It checks that live's home page answers.

If live's home page does not answer, the job fails and says which restore point to use. When the copy finishes, the owners get a notification, and so does the person who started it. Activity shows who copied what, and the job result names the restore point.

Undo a copy

Open Backups on live and restore the restore point named Before copying staging into live (or the name of the multidev). It stays 14 days, and it does not count toward your five manual snapshots. Restoring it needs the same permissions as the copy.

Using the API and the MCP server

• The API has two routes: GET /v1/environments/{id}/copy-into-live/preview (where {id} is live) and POST /v1/environments/{id}/copy-into-live. The request needs confirm: true, confirm_live: true, and live_name_confirmation. A missing one answers 422 and names it. An API key needs the backups:restore_live scope, the same as restoring live.
• The MCP tool copy_into_live asks in two steps. The first call returns the warning and the sizes. After you answer, the second call sends the confirmations and the address you typed.
• A plain push into live is refused: use this instead.

Not yet

• A promote can still carry database tables and uploads with its own, shorter confirmation. Use Copy into live for content.
• The copy is proven on the demo node. A real node needs a test run before this is called shipped.

Related

• Environments
• Push content between environments
• Push code to staging and promote
• Backups
• Sleeping environments