Remove a host
Removing a host takes it out of Fleet. It is offered in two places: on each card under Hosts in Fleet on the Overview, as a bin icon whose label names the host, and at the bottom of the host's own detail page as Remove from Fleet. Cards under Detected in Wazuh Cloud have no such control, because there is nothing in Fleet to remove.
Both places open the same confirmation dialog, whose wording differs by kind because the consequences do. On the detail page the control appears only once Fleet has confirmed it holds the host: if the control plane could not be asked, the page says so instead of offering to remove something it could not confirm exists.
This is a change to a security boundary rather than an edit to a list. What removal ends is the connector's admission to Fleet, and it ends it in three separate ways rather than one. For a Wazuh Cloud environment there is a step before all three, described below.
What removing does
Everything Fleet holds about the host is deleted in a single transaction: the registry entry, the registration of its connector, any enrolment token that was minted and never redeemed, the per-member access grants for it, any outstanding update pin and what each host last reported about its own version, the plugin records on both sides (what Fleet asked for and what each host reported), and any plugin binding along with the credential it was still carrying for a host that had not taken it yet. All of it commits together, or none of it does.
The enrolment token is deleted first and the registry entry last. That ordering is the security half of the transaction: the token is the one credential that can mint a connector registration, so taking it out of circulation before anything else closes the window in which a connector redeeming it could leave behind a registration that nothing would ever remove.
Three things close Fleet's link to the host, and they take effect at different moments.
| Step | Effect |
|---|---|
| The registry entry is gone | Every request for the host re-checks it, so access to it closes at the moment the removal commits. A request for the removed host answers the same 404 Not found as one that never existed |
| Fleet asks the gateway to evict | Best-effort, sent after the commit. When it lands, the session the connector is holding at that moment is closed straight away |
| The connector registration is gone | The gateway refuses the connector's next dial with a 403 and connector revoked |
The third step is what makes the removal durable. A connector's client certificate stays cryptographically valid for 90 days after it was issued, so without a check on every dial a connector would reconnect inside its own backoff and register again. That check fails closed: if the gateway cannot answer the question, the dial is refused rather than admitted.
The eviction is best-effort and Fleet says so. Removing a host of your own leaves a notice that reports which of the two happened. If the session was cut, it says so. If there was no live session to cut, or the gateway gave no answer, it does not claim one was cut: it says the connector is revoked, that it was not connected at the moment of removal, and that it is refused the next time it dials. Reporting a cut-off that did not happen would be a failure rendered as a fact.
Removing from the detail page takes you back to the host list instead, where the host is either gone or, for a Wazuh Cloud environment, in the detected grid on the Overview.
A Wazuh Cloud environment: Wazuh Cloud is asked first
For a Wazuh Cloud environment, Fleet asks Wazuh Cloud to retire the Fleet connector it deployed there before touching anything of its own. A connector left running after its registration is gone would dial a gateway that refuses it for ever, so the order is deliberate. Three answers stop the removal before anything of Fleet's is touched, and the dialog shows each one in the API's own words. If Wazuh Cloud does not answer: "Wazuh Cloud did not answer, so Fleet did not remove this environment. Nothing was changed; try again." If Wazuh Cloud refuses the request: "Wazuh Cloud refused to retire this environment's Fleet connector, so Fleet changed nothing." That one needs a fix on the Wazuh Cloud side rather than a retry. And if the Fleet organization is no longer paired to a Wazuh Cloud account: "Fleet is not connected to a Wazuh Cloud account, so it cannot ask Wazuh Cloud to retire this environment's connector. Connect your Wazuh Cloud account again, then remove the environment." In every case the environment stays in Fleet. An integration Wazuh Cloud reports as already gone counts as retired, and an environment the account no longer lists is removed from Fleet without asking, since its connector is gone with it.
The confirmation dialog for a Wazuh Cloud environment says what this means: "Fleet asks Wazuh Cloud to retire the Fleet connector it deployed inside this environment. The environment itself, its data and your subscription are untouched." Once retired, the connector stops, and until it stops it is refused on its next dial like an on-prem one.
What removing does not do
- Nothing about a Wazuh Cloud environment itself changes. Wazuh Cloud retires the Fleet connector it deployed and nothing else. The environment keeps running, its data stays, and the subscription is untouched. See Wazuh Cloud environments.
- Nothing on the machine is deleted. Fleet stops listing the host and revokes its connector. What runs on the machine is left as it is, and the services installed on it stop being managed from Fleet.
- The connector package is not uninstalled. Nothing in Fleet can reach into your network: the connector dials out and holds the session it opened, so there is no inbound path along which an uninstall could be sent. Removing it is done on the host, by you.
A Wazuh Cloud environment comes back as detected
The detected list is your Wazuh Cloud account de-duplicated against what Fleet holds. The registry entry is what hid the environment from it, so the moment that entry is gone the environment reappears under Detected in Wazuh Cloud on the very next list. That is the behaviour, not an omission.
Detected means Fleet found the environment in your Wazuh Cloud account and no connector is deployed for it. It is not managed in Fleet, and everything shown for it comes from your Wazuh Cloud account rather than from the environment itself.
Pressing Connect to Fleet on that card brings the environment back: Fleet asks Wazuh Cloud to deploy a new connector, and the environment returns to In Fleet as Connecting. See Wazuh Cloud environments.
A host of your own has no such list to fall back to. It leaves Fleet entirely, and bringing it back means adding it again and enrolling it against a fresh token. See Your own hosts and Add your first host.
Uninstall the connector from the host
Run this on the host itself, as root:
# Removes the binary and the systemd units. Keeps the identity, the config
# and the installed versions under /usr/local/lib/fleet-connector.
curl -fsSL https://dl.fleet.wazuh.com/uninstall.sh | sudo bash
# Also removes /var/lib/fleet-connector, /etc/fleet-connector and every
# installed version, including any plugin's binary, state and identity.
curl -fsSL https://dl.fleet.wazuh.com/uninstall.sh | sudo bash -s -- --purge
Either form stops and disables the plugins first, before the connector that
feeds them, so a plugin holding another product's identity is never left running
on a host whose owner believes they uninstalled everything. Without --purge
the plugins' binaries and state are kept. With it, the per-plugin system users
the installer created are removed too, after their processes are gone and their
files with them.
A Mobius connector is a different product that may share the host. It owns
/etc/mobius/connector.yaml and /var/lib/mobius-connector, and both are left
alone whenever its binary or unit is present, including under --purge.
More on what the connector is and what it runs: Connector overview and Connector lifecycle.
Who may remove a host
Administrators, and any member whose Can add new hosts box is ticked on the
Team page. The same permission covers adding and
removing, and it is enforced by the API rather than by the page: for anyone else
the removal answers 403. The control is not hidden from them, and the dialog
shows the console's own wording for that answer, which is the first row of the
table below.
When a removal fails
The confirmation dialog stays open with the reason in it, and the host stays exactly where it was. It is not optimistically dropped, because a row that vanishes from the page is a claim that the host is gone, and a failed request is not evidence of that. None of these messages says the host is still there, because a request that failed on the way back may well have committed.
| What came back | What Fleet says |
|---|---|
404 or 403 | "Fleet did not find it, so it may already have been removed. Reload this page to see the current list." A 404 is also what Fleet answers for a host you may not open, so it is not proof the removal happened |
502 or 503 | "Fleet could not reach the control plane. Reload this page to check whether it was removed." A request that got no answer may still have committed |
401 | "Your Wazuh ID session has expired. Sign in again and retry." |
| Anything else | The API's own message, prefixed Fleet API: |
In the playground there is no backend at all. Removals there live in the browser tab and are gone on reload, and no connector or Wazuh Cloud account is involved.