The Code tab

The Code tab is where your site's code lives. Open your site, then Code, to commit the changes made on staging, pull new commits, promote staging to live, roll back, read commits and build logs, merge branches, and set the web root for the environment you are looking at.

For how Git deploys work end to end, read How Git deploys work. For the build file, read the avaloi.yml reference.

How code runs on each environment

Environment	How code runs	What may change it
Staging	A writable working tree of the main branch	Plugin and theme installs and updates, wp-admin, SFTP, SSH, WP-CLI, the Files tab, and Git pushes
Multidev	A writable working tree of its own branch	The same as staging
Live	A read-only release built from a commit	Nothing in place. Only a promote from staging, or a rollback

The card How code runs on the Code tab says which one you are looking at. Changes on staging stay on staging until you commit them and promote.

Commit changes

When you install or update a plugin on staging, edit a file over SFTP, or change a theme in wp-admin, the change sits in staging's working tree. The Commit changes card lists it:

• files added, changed, and deleted since the last commit
• files that look like secrets, which are never committed

To save the changes to Git:

1. Open staging, then Code.
2. In Commit changes, read the list of files.
3. Write a short commit message, such as Update WooCommerce to 9.3.
4. Click Commit changes.

Avaloi commits the files to the main branch with you as the author. To commit only some files, list their paths, one per line; everything else stays uncommitted.

Avaloi never commits uploads, caches, wp-config.php, the Avaloi plugin, or the paths in the ignore: list of your avaloi.yml. Files that look like secrets, such as .env, wp-config-local.php, private keys (id_rsa), or database dumps, are left out and named in the job, so they never reach your repository. Keep secrets in environment variables.

Pull latest commits

When a developer pushes to main from their computer, or a multidev is merged into main, the card says New commits are waiting. Click Pull latest commits to bring staging up to date. Only the files that differ change.

If staging has changes that are not committed yet, the pull waits so nothing is lost. Write a commit message and click Commit and pull: Avaloi commits your changes, combines them with the new commits, and leaves staging on the result. If the same file changed in both places, nothing changes and Avaloi lists the files. Resolve the conflict in Git, push, and pull again.

A merge of a multidev into main pulls into staging on its own.

Promote staging to live

Live gets code only from staging, through the Staging to live panel at the top of the tab. A promote ships the last commit of staging, never uncommitted changes. If staging has uncommitted changes, the panel says so; write a commit message in the panel and Avaloi commits them as you before it promotes. See Staging, live, and multidev environments.

Roll back

Avaloi keeps ten releases on live. To go back:

1. Open live, then Code, then the list of releases.
2. Choose an earlier release.
3. Click Rollback and confirm.

The older code goes live without a new build. Rollback changes code only: the database and uploads stay as they are. On staging, go back by committing or by pulling an older commit from Git; staging has no releases.

Read commits and branches

The tab lists the commits on the environment's branch, newest first, and the branches in the repository. Open a commit to read it with its diff. Avaloi reads the diff from the repository through a job, so it takes a moment to appear.

Watch builds

Live builds a release from a commit for every promote. The tab lists builds, newest first, with their state. Open a build to read its log. While the build runs, the log streams new lines as they arrive. If a step fails, the build fails, and live does not change.

Merge a branch

When work on a multidev is ready, choose Merge into staging on its Code tab. Avaloi checks for conflicts first. If a file changed on both branches, the merge is refused with the list of files and no branch changes. A clean merge creates a merge commit on main, and staging pulls it.

Merging does not change live. Promote staging afterwards.

A read-only release on staging

Staging and multidevs can run a read-only release instead of a working tree, for an environment nobody edits in place. Choose Run a read-only release in How code runs. Commit your changes first: Avaloi refuses while the working tree has uncommitted changes. Choose Make code writable to go back. Live always runs a read-only release and has no switch.

Set the web root

If your site lives in a subfolder of the repository, set the web root so Avaloi serves the site from that folder. Confirm the change. The API call needs confirm: true, and Avaloi applies it through a job.

Limits

• Ten releases stay on live.
• The commit card lists up to 20 files of each kind; the commit still takes every change.

Quick answers

I installed a plugin on staging. Is it on live? No. Commit the change on staging, then promote staging to live.

I pushed, but staging did not change. Open staging's Code tab and click Pull latest commits.

The pull says staging has uncommitted changes. Commit them first, or write a message and click Commit and pull.

Why was .env not committed? It looks like a secret. Put the values in environment variables instead.

Rollback did not restore my content. Rollback changes code only. Restore a snapshot from Backups for the database or uploads.

API

• GET /v1/environments/{id}/working-tree: uncommitted changes
• POST /v1/environments/{id}/commit with {"message": "..."}: commit changes
• POST /v1/environments/{id}/working-tree/sync: pull latest commits, with {"commit_message": "..."} to commit first
• GET /v1/sites/{id}/promote/preview and POST /v1/sites/{id}/promote
• GET /v1/sites/{id}/repository
• GET /v1/sites/{id}/commits and GET /v1/sites/{id}/commits/{sha}
• GET /v1/sites/{id}/branches
• GET /v1/sites/{id}/releases and POST /v1/releases/{id}/activate
• GET /v1/environments/{id}/builds and GET /v1/builds/{id}/log
• PUT /v1/environments/{id}/code-mode (classic for a working tree, git for a read-only release; live refuses classic)
• PUT /v1/environments/{id}/webroot
• GET /v1/environments/{id}/merge-check and POST /v1/environments/{id}/merge

Related

• Staging, live, and multidev environments
• Git access
• How Git deploys work
• avaloi.yml reference
• Environment variables
• Backups