Staging, live, and multidev environments
Every site starts on staging. Launch live when you are ready, then promote changes from staging to live. Add multidevs for bigger work, clone content down, and undo mistakes with snapshots.
This article is a draft and may change.
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.
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 writable working tree of the main branch |
Build and test. Install and update plugins and themes, edit over SFTP or SSH, then commit the changes. |
| Live | A read-only release promoted from staging | Your public site. Code is read-only; uploads and content change as usual. |
| Multidev | A writable working tree of its own branch, env/{name} |
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 and a thin band of the same color under the top bar: 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.
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 such as acme-staging.avaloi.com. Search engines are told not to index it.
Change code on staging
Staging's code is writable, 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. Avaloi tracks every change against Git. When you are happy, open Code and click Commit changes: 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. Developers can also push to main from their computer; staging then shows Pull latest commits. See The Code tab.
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. If a launch fails, staging is untouched: delete the failed live environment and launch again.
API: POST /v1/sites/{id}/launch with {"confirm": true}.
Promote staging to live
Code reaches live one way: a promote from staging.
- Open Code. The Staging to live panel shows the pipeline (multidevs, staging, live) and lists the commits and files that staging has committed and live lacks. If staging has uncommitted changes, the panel says so: write a commit message there and Avaloi commits them as you before it promotes, or commit them yourself first.
- Choose what to copy. Code always moves. You can also copy the database (all tables or some) and uploads (all folders or some). Copying content replaces what live has, so Avaloi asks you to confirm that separately. Leave it off when live has orders, comments, or posts you want to keep.
- 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. If a deploy hook fails, live keeps the code it had.
If someone changed staging after you opened the panel, the promote stops and asks you to look again, so live never gets code nobody reviewed.
The panel follows each step (build, copy content, switch, check). To undo a promote, choose Undo: roll back live when it finishes, or roll back to any earlier release in the live environment's Releases list. 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", "uploads", and "confirm_content_overwrite": true to copy content.
Multidevs
Agencies can add more environments for bigger work. Give one a name, such as qa or checkout, and Avaloi makes the branch env/{name} from main, clones staging's database and uploads, replaces the hostname, and builds the branch. 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 memory.
When the work is ready, open the multidev's Code page and choose Merge into staging (it merges the branch into main). 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, and staging pulls it. Then promote staging to live as usual.
Clone content down
To refresh staging or a multidev with what live has now, choose Clone content. Pick the tables and uploads folders, then confirm. Avaloi takes a snapshot first, copies what you picked, and replaces the live address with the environment's own. Code never moves this way, and you cannot clone into live: content reaches live through a promote.
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
Deleting a multidev 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.
Quick answers
Can I deploy straight to live? No. Change code on staging, commit it, check it, then promote. Rolling back to an earlier live release still works.
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.
Related
Still stuck?
Email [email protected] with your site name and what you tried, or send us a message.