Staging, live, and multidev environments

Every new Avaloi site starts on staging. Build the site there, show it to your client on its staging address, and launch live when it is ready. After that, every code change starts on staging and reaches live through a promote. Live is never edited directly: nobody can change its code from wp-admin, SFTP, or a hacked plugin. Uploads on live keep working as normal, and live owns them: the media library works, and a promote never overwrites live's uploads unless you ask.

What an environment is

An environment is a database, a content store (your wp-content/uploads folder), and a release of your code, running in its own container on its own temporary hostname. Each one has a role:

Role	What it runs	What you do there
Staging	A read-only release of the main branch (Git mode). In SFTP mode, a writable working tree of it	Build and test. Push code with Git. Switch to SFTP mode to install plugins in wp-admin or edit over SFTP, then commit.
Live	A read-only release promoted from staging	Your public site. Code is read-only; uploads and content change as usual.
Multidev	A read-only release of its own branch, env/{name} (Git mode). In SFTP mode, a writable working tree of it	Bigger changes and experiments, merged into staging when ready.

The environment switcher at the top of the site shows which environment you are on, with a colored badge: amber for staging, green for live, and blue for a multidev. Every tab then works on that environment, and the address of the page keeps it (?env=), so a link you share opens the same environment. The switcher's Manage environments item opens one page with every environment.

A new site starts on staging

When you add a site, Avaloi creates its staging environment: WordPress on the main branch of a new repository, its own database, and its own uploads, on an address with a random ending, such as acme-staging-k3x9q.avaloi.com. Search engines and AI crawlers are kept out of it (see Staging privacy).

Change code on staging

The first card on staging's Info page is Code. It shows the flow in order:

1. Development mode, with an SFTP | Git switch and Clone with Git. New staging and multidev environments start in Git mode: code changes only by a Git push, a merge, a pull from a connected repository, a promote, or a reset from live, and wp-admin cannot install or update plugins or themes (you can still activate and deactivate them). Switch an environment to SFTP mode when you want writable code, like a traditional host: install and update plugins and themes in wp-admin or on the Plugins tab, edit files over SFTP, SSH, or the Files tab, and run WP-CLI. Switching to SFTP mode loses nothing, because the working tree starts as a copy of the code the environment runs now. Switching back to Git mode needs your uncommitted changes committed first: Avaloi says how many there are and offers Commit and switch or Discard and switch. Environments made before this default keep their mode.
2. N uncommitted changes (SFTP mode), with the files and a Commit changes form. Avaloi saves the files to main with you as the author, and leaves out uploads, caches, wp-config.php, and anything that looks like a secret. When developers push to main from their computer, an environment in SFTP mode with a clean working tree pulls the push in by itself. With uncommitted changes, the card says New commits are waiting and offers Pull latest commits. In Git mode, a push builds a release automatically.
3. Commit history, newest first, with a Diff button on every commit.

When live has been launched and staging has commits live lacks, the top of the card says how many and links to live: "3 commits are ready for live. Go to live to deploy."

SSH keys, HTTPS tokens, and connecting GitHub, GitLab, or Bitbucket stay in the cards further down Info. See Git access and Connect GitHub, GitLab, or Bitbucket.

Launch live

When the site is ready, choose Launch live on the Info tab, in the environment switcher, or in the top bar. Live uses the plan slot the site already holds, so launching adds no charge. Avaloi creates the live environment from staging: a copy of staging's database and uploads, the code staging runs, its own address (such as acme.avaloi.com), and a certificate. Live lets search engines in. Staging stays as it was, so you keep working there.

Launch live needs staging to be running, with its changes committed: live starts from the last commit of staging. (Staging in Git mode always runs a commit. In SFTP mode, commit first.) If a launch fails, staging is untouched: delete the failed live environment and launch again.

API: POST /v1/sites/{id}/launch with {"confirm": true}.

Deploy staging to live

Code reaches live one way: a deploy (a promote) from staging. You never have to look for it: pick Live in the environment switcher, and the first card on Info is Deploys.

1. Each time the page opens, Avaloi compares staging with live by itself. When nothing is new, the card says "Live is up to date with staging. Nothing to deploy." and Deploy to live stays off. Otherwise it says how many commits and files are ready, and lists the commits with a Diff button on each.
2. If something stops the deploy, the card says what and how to fix it. Uncommitted changes on staging in SFTP mode show Commit changes on staging, which opens staging's Code card. You can also deploy with a commit message, which commits them first. A deploy ships the commit staging runs, and the dialog shows the mode of each side (Git or SFTP).
3. Add an optional deploy note. Code always moves. To also copy staging's database (all tables or some), open Also copy content from staging. Copying tables replaces those tables on live, so Avaloi asks you to confirm that separately. Leave it off when live has orders, comments, or posts you want to keep.
   • Copy new uploads from staging merges staging's uploads into live's. It adds files live does not have and files that changed on staging, and the dialog counts them first: new, updated, and "differ and are newer on live". It never deletes a file that only live has, and a live file that is newer than staging's copy stays as it is. Merging needs no extra confirmation. PHP files are never copied.
   • Overwrite files that differ also replaces the live files that are newer than staging's copy. Live's media is the customer's own, so this asks for the overwrite confirmation. It still deletes nothing.
   • Before any content moves, Avaloi takes a restore point of live that includes its uploads, so a merge can be undone from Backups.
4. Click Deploy to live and type the site's name to confirm. Avaloi builds the commit, takes a restore point of live, and switches live to the new code in one step, with each step shown in the card. If a deploy hook fails, live keeps the code it had.

Below it, Deployment history lists every deploy to live: the commit message, who deployed it, and when, with Show more for older ones and Roll back on earlier releases. The Promote to live button in the Environment details card on staging does the same thing and stays for those who prefer it.

If someone changed staging after you opened the dialog, the promote stops and asks you to look again, so live never gets code nobody reviewed.

To undo a deploy, choose Undo: roll back live when it finishes, or Roll back next to any earlier release in Deployment history. Restore the restore point to undo copied content.

API: GET /v1/sites/{id}/promote/preview, then POST /v1/sites/{id}/promote with {"confirm": true, "sha": "<staging commit>"}. Add "commit_message" to commit staging's changes first. Add "database" to copy tables (with "confirm_content_overwrite": true). Add "uploads" ("all" or a list of folders) to merge uploads: the preview shows content.uploads_merge with new_files, changed_files, and conflict_files. Add "uploads_overwrite": true with "confirm_content_overwrite": true to also replace live files that are newer than staging's copy.

Multidevs

Agencies can add more environments for bigger work. Open the environment switcher in the top bar and choose Create environment. First pick the kind: a Standard environment is free, and a Premium environment shows its monthly price from the add-on catalog. Choose Continue, give it a name, pick the Environment to clone (staging, or live once it runs) and the branch to start from, such as qa or checkout. Avaloi makes the branch env/{name} from the source's last commit, clones that environment's database and uploads, replaces the hostname, and builds the branch. The new multidev starts in Git mode. If the source is in SFTP mode with uncommitted changes, commit them first, because the new branch starts from a commit. Avaloi can only create an environment by cloning another one, so a new WordPress install and an empty environment are not offered.

While the node makes the environment, every tab of the new environment shows one page, Creating {name} environment, with the progress. You can leave it. Avaloi shows a message when the environment is ready, and the page turns into the real tab by itself. A site can have up to 10 standard staging and multidev environments, which run on a small profile with 2 PHP threads, a 512 MB PHP pool, and one CPU core. On top of those, a site can have up to five premium staging environments, with half of live's PHP threads and PHP memory on one CPU core at most, so they never slow live. A premium environment uses a premium slot: your plan's first, then slots you buy for 20 USD a month. When no slot is free, the Create environment dialog shows the monthly price and the amount charged today, and creating the environment buys the slot. See Premium staging environments.

A multidev's Code card checks it against staging by itself. When the multidev has commits staging lacks, it shows how many and turns on Merge into staging; when there is nothing new, the button stays off and says so. You can also merge from Manage environments or the environment bar. Avaloi checks for conflicts first; if a file changed on both branches, nothing changes and you get the list of files. A clean merge creates a merge commit on main. Staging in Git mode builds and runs a release of the merge commit; staging in SFTP mode pulls the merge into its working tree. When either side is in SFTP mode, both sides must have no uncommitted changes, or the merge answers 409 working_tree_dirty and nothing changes. Then deploy staging to live as usual.

Manage environments

Open the environment switcher and choose Manage environments. The page lists every environment: its name and role (Live, Staging, or Multidev), who deployed it last and when, its address, and its status. Each multidev shows two numbers with a small bar: how many commits it is behind staging and how many it is ahead. Merge works only when it is ahead; Delete is there for multidevs only. Create environment adds a new one. The old Overview of all environments page opens this page now.

Push environment

The Info page has a Push environment menu in its header. On staging it offers Push to Live, which opens the same promote steps as Deploy to live (once live is launched). On live it offers Push to Staging, and on any environment it offers a push into each running staging or multidev environment, which copies database tables and uploads (see Push content between environments). While a job is running on the environment, every entry is off, and pointing at one says that the environment is busy. Wait for the job to finish, then push. The menu shows only what you may do and what exists: no Push to Live before live is launched.

Environment details

The Environment details card on live shows whether the CDN and edge caching are on, and the address other services see when your site calls them (IP address for external connections). Staging and multidevs sit behind neither: the card shows the CDN and edge caching as off, and has no external connection address.

Clone database and files

To refresh staging or a multidev, use the Clone database and files card on its Info page. Pick From environment (live, staging, or another multidev), tick Clone database, Clone files, or both, and optionally Clear caches after the clone. URLs are converted from the source's address to this environment's address for you; the card names both. Click Clone to Staging (or the multidev's name) and type the environment's name to confirm. Avaloi takes a snapshot first, then copies what you picked. Code never moves this way. (Reset staging from live is the exception: it builds live's commit as a release on staging. The main branch itself is not rewound.) You cannot clone into live: content reaches live only through the content options of a deploy. To pick single tables or folders, use Clone content into it in the row menu on Manage environments.

Snapshots and restores

A snapshot holds an environment's database and uploads, with a note of the PHP version, how code runs, and the commit. Avaloi takes one before every risky change (a promote, a PHP change, a search and replace, a clone, a restore) and keeps it 48 hours. You can take up to five manual snapshots per environment from the Backups tab, kept at least 14 days.

To restore, pick a snapshot and choose the database, the files, or both, into the same environment or another one of the same site. Every restore takes a snapshot first, so a bad restore is one click to undo.

Deleting environments

To delete a multidev, click Delete on its row in Manage environments (or use its row menu in the environment switcher). Deleting keeps a snapshot of its database and uploads for 30 days and keeps its branch, so you can create it again. Staging and live go only with the site; deleting the site removes every environment. Deleting a premium environment frees its premium slot but does not remove a slot you bought. That slot keeps billing monthly until you remove it on the Add-ons page.

Quick answers

Can I deploy straight to live? No. Change code on staging, commit it, check it, then deploy from live's Deploys card. Rolling back to an earlier live release still works.

Can I install a plugin on staging from wp-admin? Not while staging is in Git mode, which is the default. wp-admin says: "This environment is in Git mode. Commit the change and push it with Git, or switch this environment to SFTP mode to install from wp-admin." Push the plugin with Git, or click Switch to SFTP mode.

Can I install a plugin on live? No. Install or update it on staging, commit the change, then promote. On live you can still deactivate a plugin or switch the theme.

Do uploads on live still work? Yes. Media and other uploads on live are content, not code. The media library, form attachments, import files, and plugins that save files in wp-content/uploads all work on live. Those files belong to live: a promote, a rollback, a restore of code, or a restart never touches them, and a promote copies staging's uploads to live only if you choose that, and then it only adds files and never deletes any. The Files tab can browse, upload, rename, and delete inside the uploads folder on live, and in wp-content/cache, which plugins rebuild. PHP files never run there. See Manage files.

Where do live's uploads go when I create staging or a multidev? They are copied. Staging and multidevs start with a copy of live's uploads. Clone database and files and Reset staging refresh that copy from live, and launching live copies staging's uploads to live once.

Related

• Premium staging environments
• How Git deploys work
• avaloi.yml reference