Docs / Server agents

Server agents

Connect a server, ask it questions on WhatsApp, and deploy to it. A new server can only look at things until you say otherwise, and the actions that cannot be undone are never offered in a chat.

Connect a server

In the console, open Servers and press Connect a server. You are given one line to run on the machine, as root. If you have never used a terminal, your hosting provider has a web console and it works there too.

On your server

curl -fsSL https://github.com/kunshort/wavesenda-agent/releases/latest/download/install.sh \
  | sh -s -- wss…

The token is shown once and stored as a one-way hash, so it cannot be read back. If you lose it, make a new one from the server’s page — which is also how you revoke a machine you no longer trust.

Read the installer before you run it

It is published beside the binaries in every release, it is about a hundred lines, and the top of it lists everything it does. We are asking you to pipe a script from the internet into a root shell, and being casual about that would teach exactly the wrong habit.

The agent creates a user that can log in nowhere, installs a service, and writes a sudoers file naming the three commands it may elevate — not ALL. It opens no ports: it dials out to us, so nothing connects in.

What it may do

Everything an agent can do to a server is a fixed list, and the list is grouped by how much damage each group can do. A newly connected server has only the first group.

Group	Examples	What happens
Looking	service.status · logs.tail · disk.usage · cert.expiry · http.check	Runs straight away. These change nothing, and a chat that asks permission to check whether your site is up is a chat nobody opens twice.
Changing	service.restart · deploy.run · deploy.rollback · cert.renew	Asks you to confirm in the thread, then asks for a code emailed to you. Records how to reverse itself before it runs.
Cannot be undone	db.drop · firewall.set · ssh.keys	Never offered over WhatsApp at any level of insistence. Done from the console, signed in, with the action’s own name typed to confirm.

Why the last group is not simply “ask twice”

The usual safeguard for a risky action is to ask a person first. That works when the person can judge the answer — and somebody who knew that dropping a table was the wrong move would not need an agent to run their server. Asking them to approve it only moves the blame, so the category is removed instead.

Who may ask

Every other agent in WaveSenda answers whoever writes to the number. A server agent does the opposite: it answers a list, and says nothing at all to anybody else — not even a refusal, because telling a stranger that this number commands a server tells them it is worth attacking. You are told somebody tried.

An operator is bound by number and then by the WhatsApp account their messages actually arrive from. If that account changes — a new phone, a restored backup, or somebody else holding it — the seat stops working until you re-bind it in the console.

The code goes to your email, not your phone

A second factor on the same device as the first is not a second factor. Somebody who has taken over your phone has your WhatsApp; the email is somewhere else.

One code opens a short window rather than being asked for on every action. A code typed forty times a day stops being read, which is the conditioning that makes those attacks work. Set the window to zero on a server where you want to be asked every time, and production servers always are.

Deploying

Connect a repository through the GitHub App and the agent can put your code live. It asks for read access to your code and nothing more — an agent that deploys does not need to be able to change what it deploys.

Each deploy builds into its own release directory beside the running one, switches over atomically, and then checks that your site answers. If the check fails, the previous release is put back automatically and the message you get says so. The old release stays on disk, so undo is instant for the next hour.

A push to your main branch does not deploy. It tells you what arrived — the commit message, who pushed it — and offers to. Automatic deployment on push is a feature for people who have tests.

The repository lives on the server, not in our database

What a deploy job carries is a branch or commit name, and nothing else. If our side decided which repository your server cloned, a break-in here would be a way to run code on every customer’s machine — so that setting is on the machine itself.

What it costs

Asking a server something is an AI reply like any other and uses credits by what the model actually costs. The actions themselves cost nothing — the work happens on your own machine, on hardware you already pay for.

Each plan includes a number of changes per server per month. That is a ceiling rather than a price: going over refuses the change and deducts nothing, and you can still ask questions. Undoing something never counts against it.

Settings worth knowing about

Setting	What it does
This is production	Every change asks for a fresh code, with no open window. Worth setting on anything customers can see.
Code window	How long one code keeps the door open for further changes. Zero asks every time.
Changes this month	The ceiling for this server. Lower it on a staging box nobody should be able to use up the month on.
Pause everything	Stops the server answering at all and abandons anything waiting to be confirmed.
New install key	Issues a new token. The running agent stops at its next poll — this is how you take a server away.