Fleet/Installing the agent

Installing the agent

Three commands, and the one decision you should make deliberately.

Install

bash

# 1. Authenticate this server against the control plane
accelerated login --server https://monitoring.qrdev.org

# 2. Install and start the systemd service
accelerated install

# 3. Confirm
accelerated status

login uses a device-login flow: it prints a code, you approve it in AccelerUp, and the agent receives an enrolment token. The server never holds a user's credentials.

Choose the profile deliberately

This is the one decision worth thinking about, and it is made on the machine:

Profile	Use for
`observe`	Anything you only want to watch. Sensitive hosts, third-party managed boxes, anything where a shell would be a compliance problem
`operate`	Most servers. Declared commands and unit restarts, no interactive shell
`full`	Boxes you genuinely administer from AccelerUp

bash

ACC_PROFILE=operate accelerated install

Important

The profile cannot be widened from the control plane. Choosing observe now and changing your mind later means going back to the machine — which is the intended cost.

The profile is logged at every start, not only when it blocks something:

text

accelerated 0.11.0 starting — 0 app(s) interval=30s threshold=3 profile=observe …
  profile=observe — this machine reports only: no shell, no file transfer,
  no commands, no failover. Set ACC_PROFILE to widen it.

Servers with no blue/green

An agent with no blue/green application configured is a normal, supported setup — a database box, a worker, a build host — and it still reports vitals, ships logs, runs probes and executes commands. The startup log says so plainly rather than leaving it to be inferred from silence.

Verifying

bash

systemctl status accelerated
journalctl -u accelerated -f
accelerated status

In AccelerUp the server appears under Fleet → Overview within a minute.

When the websocket will not connect

Connection and Upgrade are hop-by-hop headers; any proxy may drop them.

bash

curl -i https://monitoring.qrdev.org/api/v1/agent/ws-check

That endpoint is public and inert: it upgrades, reports whether the upgrade survived the proxy chain, and closes. It exists because a failed handshake is otherwise invisible from both ends.

Uninstalling

bash

accelerated uninstall

Stops and removes the service. Remove the server in AccelerUp afterwards, or it will alert as having stopped reporting — which is the correct behaviour and not what you want here.

Upgrading

Do not upgrade by hand across a fleet. Use Agent rollout, which goes canary first and stops on failure.

Where this behaviour lives: backend/cmd/accelerated/main.go. If the code and this page disagree, the code is right — please fix the page.

Part of Fleet — The agent on each server: what it collects and what it may be asked to do.