Support access

Avaloi staff never open your site on their own. They can act on it only while you have given access, only for the things you allowed, and only until the time you set. You can end the access whenever you like.

Give access

Open your site and choose Support access in the sidebar. Press Give access, then choose:

• What support may do. Tick only what you need. See the table below.
• How long. From 1 hour to 7 days. The default is 24 hours. The access ends by itself.
• A note for support, if you want to say what to look at.

Owners, admins, and the site's manager (a Site Admin of that site) can give access. Developers, Billing users, and viewers cannot. An API key or an AI agent can never give access, because a person has to approve it.

To cover every site at once, open Company settings, then Support access, and press Give access to all sites. Only owners and admins can do that. A company wide grant covers sites you add while it lasts.

You can also give access from a support ticket, or by confirming an offer in the support chat. See "Answer an offer" below.

What each choice allows

Choice	Staff can
View and diagnose	See the site's status, plugin and theme lists, and logs. Run read-only WP-CLI commands. Turn off a plugin that breaks the site.
Restart services	Restart PHP, the web server, or the container, and clear caches. Move the site to another server (see Moving your site to another server).
WordPress admin sign-in	Open your WordPress admin as one of your users, or as a temporary support administrator. The link works once and expires in 60 seconds. On a WordPress Multisite network, staff can also open the Network Admin, but only with this choice, and only while one click login is on in Tools.
Files and database	Read and edit files, read the database, run one guarded database statement with a reason, run commands, and roll back to an earlier release.
DNS and domains	Check domains and DNS records, run a domain's setup again, re-issue a certificate, and fix a record in a DNS zone Avaloi hosts.

Staff roles are limited too. A support agent cannot use the files and database tools even if you allow them. A second person with the right role has to take that case.

Live code stays read-only in Git mode, whatever you allow. Staff edit the staging copy, and you or they promote it.

See what staff did

Every action names the staff member, the time, and the access it ran under. You see them in three places:

• Under each grant on the Support access page. Press What staff did.
• In User activity and in your company's activity log.
• In an email when the access ends. It lists each action in order.

The temporary support administrator, if staff made one, is removed when the access ends.

On a Multisite network, a Network Admin sign-in makes that temporary administrator a super administrator for the length of the access. The activity log says "Network Admin" on that entry. When the access ends, Avaloi removes the super administrator right first, then deletes the user from the whole network, not just from one site.

End access

Press End access on a grant, then confirm. Staff lose access at once, any temporary administrator is removed, and you get the summary email. Access that runs out on its own ends the same way.

Recorded shell sessions

When you allow Files and database, staff can open a recorded shell session on your site. It is a console for running commands, with four rules.

• Only with your approval. Staff need your active Files and database access. A support agent never gets a shell. The one exception is a container that Avaloi owns itself, where no customer exists to ask. Only operators and admins can open those, and the session is recorded the same way.
• One command at a time. Each command runs as a job on your site's container, with an audit entry that names the staff member. There is no live terminal, and a second command cannot start while one runs.
• Time limits. A session ends after 10 minutes without a command, after 2 hours in all, or when staff close it. It also ends the moment your access ends, if you end it early or it runs out.
• Dangerous commands ask twice. A command that can destroy data, such as deleting the site or wp-content, dropping or resetting the database, changing DNS, or shutting the machine down, needs staff to type a phrase first. The activity log shows that they did.

On a live site in Git mode, only plain read-only commands run, as with all staff tools.

Read the transcript

While a session is open, you can see that it is open and how many commands ran, but not what was typed. When it ends, open Support access, press Recorded shell sessions under the grant, then Read transcript. You see every command, its exit code, and its output, in order, with the staff member's name and the reason they gave. The transcript is read only.

Avaloi masks values that look like passwords, tokens, or keys in the command and in the output. Masking is not perfect, so treat the transcript as private. Owners, admins, and the site's manager can read it. Developers, Billing users, and viewers cannot.

Answer an offer

Support may ask for access from a ticket or in the chat. The offer appears on your Support access page and in the chat. Nothing starts until you press Allow access. You can keep fewer of the things staff asked for, and a shorter time, but never more. Press Decline to say no.

Avaloi checks that the person who answers may give access to that site. Someone from another company, or a user without the right role, cannot.

For developers

These routes need a signed-in session. Each answers 403 to API keys.

• GET /v1/sites/{id}/support-access lists the grants that cover a site.
• POST /v1/sites/{id}/support-access gives access to a site. Send scopes and duration_hours.
• GET /v1/companies/me/support-access lists every grant in the company.
• POST /v1/companies/me/support-access gives access to every site.
• GET /v1/support-access/{id}/actions lists what staff did under a grant.
• GET /v1/support-access/{id}/shell-sessions lists the recorded shell sessions under a grant. GET /v1/support-access/{id}/shell-sessions/{session_id} returns one transcript, with after and limit for paging. Both are read only. While a session is open, content_hidden is true and entries is empty.
• POST /v1/support-access/{id}/accept and POST /v1/support-access/{id}/decline answer an offer.
• DELETE /v1/support-access/{id} ends access.

The scopes are view_diagnose, restart_services, wp_admin_login, files_database, and dns_domains.

What staff see without access

Without your approval, staff can see platform health (node status and job failure counts), and a site's name and status. They never see your content, your logs, your files, or your database.

Not yet

• Avaloi also moves sites between servers on its own, to balance the load or to empty a server before it is removed. That needs none of your approval, because nobody reads or changes your content: the site is copied from one server to the other. Each move is in your activity log. See Moving your site to another server.
• Staff do not get a live terminal. A recorded shell session runs one command at a time, so every command is a job you can read afterwards.