Git access: push your code over SSH

Open your site, then Code. The Git access card at the top shows everything a developer needs to push code: the SSH address, the keys that may sign in, the branches, and one block of setup commands.

Before you start

You need an SSH key pair on your computer. If you do not have one, run this and press Enter at the prompts:

ssh-keygen -t ed25519 -C "[email protected]"

The file that ends in .pub is your public key. It is safe to share. Never share the other file.

Add your SSH key

1. On the Code tab, find SSH keys in the Git access card.
2. Type a name that tells you which computer the key is on.
3. Paste the whole contents of your .pub file.
4. Click Add key.

Avaloi installs the key on the site through a job, and the key appears in the list when the job ends. To end a key's access, click Remove next to it. Only members with SSH access permission see the add and remove controls. Everyone who can see the site can read the list.

The same keys work for SSH and SFTP sign-in. They are managed in one place, so a key added on Info shows here too.

The SSH address

The card lists the host, port, and user for the live environment, then the full address:

ssh://USER@HOST:PORT/PATH/TO/REPOSITORY.git

Copy the clone command to start from a fresh folder, or copy the remote command to add Avaloi to a repository you already have.

If the card says Git over SSH is not switched on for the node, the address is not ready yet. The host, port, and user still show. Keys you add now work for Git as soon as the node serves the repository. If it says SSH is turned off, turn SSH on under Info first.

Copy the setup commands

Click Copy setup commands. The block holds no secret. It makes a key, clones the site, switches to your staging branch, commits, and pushes. Paste it into a terminal and edit the commit message.

Branches and the deploy flow

The Branches list shows each branch, its latest commit, and which environment runs it. Staging runs main; each multidev runs its own env/{name} branch. Live runs releases of main that were promoted from staging.

1. Push your work to main (or to a multidev's branch).
2. Open staging's Code tab. It says New commits are waiting; click Pull latest commits. Staging's working tree takes your commits, changing only the files that differ.
3. Check the staging site. When it is ready, promote staging to live from the Staging to live panel. Avaloi takes a restore point, builds the release, and switches live to it.

If someone changed code on staging (a plugin update in wp-admin, an SFTP edit) and has not committed it, the pull waits so nothing is lost. Commit those changes first, or write a message and click Commit and pull: Avaloi commits them, combines them with your commits, and staging ends on the result. If the same file changed in both places, nothing changes and Avaloi lists the files. Pull the latest main, resolve the conflict on your computer, and push again.

Changes made on staging and committed there show up in Git like any other commit, with the person who committed as the author. Run git pull before you start work.

Pushing never changes live. Live code is a read-only release, so a promote from staging is the only way new code reaches it.

Quick answers

Git says permission denied. Check that the key you added is the one your computer offers. Run ssh -v with the same host, port, and user to see which key it tries. Then check the key is in the list on the Code tab.

The clone address is missing. The node has not reported a repository path yet. See "The SSH address" above.

I pushed, but staging did not change. Click Pull latest commits on staging's Code tab.

I pushed, but live did not change. Live changes only by a promote. Pull into staging, check it, then promote staging to live.

API

• GET /v1/sites/{id}/repository returns the SSH address in git_ssh.
• GET /v1/environments/{id}/ssh lists keys.
• POST /v1/environments/{id}/ssh-keys adds a key. It returns a job.
• DELETE /v1/environments/{id}/ssh-keys/{key_id} removes a key. It returns a job.
• GET /v1/sites/{id}/branches lists branches.
• GET /v1/environments/{id}/working-tree shows uncommitted changes and whether new commits are waiting.
• POST /v1/environments/{id}/working-tree/sync pulls the new commits. It returns a job.

Related

• The Code tab
• How Git deploys work
• SSH and SFTP