After deployment, use your authorized assistant to inspect the VPS and request supported operations. Start with the service identity and current status, then decide what to change. Reading status and changing the server require different levels of access; grant only what the task needs.
What you can do from the chat
- Read live status: power state, CPU, memory, disk, network and uptime
- Power actions: start, reboot, graceful shutdown or a hard stop
- On-demand backups, plus a list of what backups exist
- Reinstall from an OS template when you want a clean slate
Operate it
Find the server
Ask your assistant to list your services. Each VPS has a service id, and that is what every other action refers to.
Check the status first
Pull the live state before acting: power state plus CPU, memory, disk, network and uptime. This is read-only, so it is the part you can grant with nothing but a read scope.
Reboot or shut down
Ask for a reboot, a graceful shutdown or a start. Prefer the graceful shutdown, which signals the operating system to close down properly, over the hard stop that cuts power immediately.
Back it up on demand
Request a whole-VPS backup where supported by the service, then check its status until it completes. Confirm which service and recovery point you are using before a change. Application backups are a separate operation, described below.
A reinstall wipes the VPS and lays down a fresh OS template. Every file, database and configuration on the disk is gone, and there is no rollback. Before you ask for one: take a backup, confirm it actually completed in the backup list, and make sure anything you need is also stored somewhere off that server. Only then reinstall.
The graceful shutdown lets the system flush pending writes and close databases cleanly. The hard stop is the equivalent of pulling the cord: use it only when the machine is unresponsive and a graceful shutdown has already failed. Either one takes the server offline, so expect downtime for anything it serves.
Reading status needs very little. Rebooting, backing up and reinstalling sit behind the manage scope, which is also what allows spending. Grant it for the task at hand and revoke it afterwards: see connect your AI agent with OAuth.
A reinstall asks for a new root password. Generate a long random one in your password manager rather than reusing an old password, and never paste it into a shared chat log or a ticket.
Whole-VPS backups and app backups serve different jobs
A whole-VPS backup covers the virtual machine through the supported VPS service. An app backup targets the deployment’s covered data and uses the Impreza S3 storage associated with your account. App backups do not replace an OS recovery plan, and restoring the whole VPS can affect every application on it.
For an app-level change, inspect the app’s backup history and schedule in My Apps or through the corresponding MCP tools. Check storage capacity and a completed backup before requesting a restore. The restore keeps displaced data aside, but that copy consumes disk and is not a second off-server backup.
To move an application, restore its completed backup into a compatible destination and test it before switching traffic. Keep whole-server recovery, application recovery and traffic changes as separate decisions. See the catalog app workflow for deployment and the next steps.
Inspect the app before changing the whole server
An app problem does not always need a VPS reboot or reinstall. On supported agent deployments, inspect app logs and files, use the app’s supported maintenance commands or review scheduled-task output. The browser app terminal works inside the application; it is not a root terminal for the host.
Choose the smallest operation that addresses the problem, review its effect and authorize it deliberately. For connection and access settings, use the OAuth guide.
Use app-level tools for app-level work
Before changing the whole server, follow the app inspection and maintenance guide for supported deployments. Use limited delegated credentials when handing a specific task to another agent; app resources and VPS service resources are different permission targets.
For integrations, receive selected platform events at your own receiver. An event is a signal to check the relevant state, not a guarantee that every asynchronous operation finished.
Start now
Spin up an offshore VPS, connect your assistant with OAuth, or read the documentation.