Appliance Commands

The ironflock appliance commands install the IronFlock appliance on a Linux server you run yourself, and look after it from then on. You use them to install the appliance, to change its settings, to update it, to start, stop and restart it, to read its logs, to reset the admin password, to back up, restore and rotate its secrets, and to remove it again.

The appliance is the complete IronFlock system on one machine on site. What it is, its HTTPS modes, its network and its operation are described under IronFlock Appliance. The requirements of the machine (CPU, memory, storage, time synchronization) are on its Installation page.

Note: These commands are new in release 2.1.0 of ironflock. They passed one test run, from appliance install to appliance remove --purge, on a fresh Ubuntu 24.04 virtual machine (amd64). Not proven yet is an update that fails, with its rollback to the release before.

The Appliance

The appliance commands run on Linux. appliance install needs a Debian or Ubuntu based system with systemd. On macOS the commands end with exit code 3 before they look at anything; run them on the appliance’s machine, or from the Mac with --host.

Run them as root, with sudo. A command that changes the system ends with exit code 3 without root, and does not call sudo itself (Root Privileges).

Each command also takes the global flags --yes, --json, --download-base, --host, --hosts and --parallel (Global Flags). A question needs a terminal; without one, give --yes (Questions and Confirmation).

ironflock status shows the installed appliance: its version and channel, the address of its UI, whether its license is present, its service, the health of its services and an update that waits (ironflock status).

What an Installed Appliance Looks Like

Besides ironflock.service, the install sets up a watchdog, which checks the router and the backend every five minutes and restarts ironflock.service when they are not well, at most once in five minutes, and a timer that tries a failed update of the UI again every hour.

Keep /usr/local/bin/ironflock in place: the appliance’s units run it at every start. appliance install refuses to run from another place and says how to install it there. ironflock status, run as root, warns when that binary is missing or older than the one that last installed or updated the appliance. sudo ironflock self-update replaces it with the newest release (ironflock self-update).

The appliance also runs the host’s own device agent, which appliance install installs unless you give --no-agent. That agent is looked after with the agent commands.

One Change at a Time

One install, update or other change of the appliance runs at a time. A second one waits for the first and says so:

Another IronFlock install, update or other change of the appliance is running on this host (process <pid>); waiting up to <time> for it to finish

install, update, configure, rotate, revoke-direct-access, reset-admin-password and restore wait up to an hour. start, stop, restart and remove wait up to 30 seconds. When the other run still goes on then, the command changes nothing and ends with exit code 3.

ironflock appliance install

Installs the IronFlock appliance in /opt/ironflock and starts it. It waits until every service is healthy and the IronFlock cloud reaches the appliance, then shows the admin login of the web UI, once, on a terminal.

ironflock appliance install --license-file <file> [flags]

Runs on: a Debian or Ubuntu based Linux with systemd. Root: required.

The install sets up:

• the release of the channel, or the one --version names, checked against the appliance’s release key;
• the appliance’s configuration and secrets;
• the host’s own device agent, and Docker when it is missing;
• the host’s settings;
• Docker’s login to the registry with the license key;
• the images of the release;
• ironflock.service.

When Docker is missing, the install runs Docker’s install script from get.docker.com as root. That download is protected by TLS only.

The HTTPS modes and what each one encrypts are described in HTTPS & Certificates and Security. The proxy password follows the rules in Secrets: a proxy URL with a password in it is a wrong command line.

The License Key

The license key is the Instance Key you create on ironflock.com under Profile → Instances (Installation). It comes from --license-file or --license. An appliance that is installed already keeps its key without either. A key in license.env that is not a valid license key (a license key is a UUID) is ignored, with a warning, by every appliance command; the run then needs a key, or --skip-login.

Environment Variables

Some flags take their default from an environment variable:

sudo drops most variables of your shell. Pass them with sudo env NAME=value ironflock appliance install ....

The Record of the Install’s Choices

<install-dir>/install.json, root’s alone, keeps the choices that neither .env nor the units keep: the registry and its user, the appliance’s host (IRONFLOCK_APPLIANCE_HOST), --no-agent, the download base of --bucket-url, and the version of the ironflock that last installed or updated the appliance. It holds no password, token or key.

A later appliance install, an appliance update and appliance configure keep these choices unless a flag (or its variable) says otherwise. A flag given wins and is recorded. To go back to a default, give --registry "", --no-agent=false or an empty IRONFLOCK_APPLIANCE_HOST.

A record that cannot be read, or one of a later format, stops install, update and configure before they change anything, with exit code 3. The message says what to do: move the record aside and install again with the flags, or use the newer ironflock.

Running It Again

Run on an installed appliance, the command brings it to the release and the options given, and keeps its secrets and settings. Use this to change the release on purpose: ironflock appliance install --version <version> pulls, restarts and checks that release again, also when it runs already.

A run that stopped continues from where it stopped when the same command runs again.

Once its health checks have passed, the install removes the copy of a release before that an update kept (/opt/ironflock/.update-previous): the release it installed is the one to run.

From its first change on, a lost terminal or SSH session (SIGHUP), or output that nobody reads any more (a closed pipe), does not stop the install. Ctrl-C and SIGTERM do. The install keeps writing to the terminal after a lost SSH session, so that the admin password is not lost. With sudo’s use_pty setting, a terminal that stays open but is no longer read can therefore hold the install up while it holds the install lock.

Examples

# Install the appliance; the license key comes from a file
sudo ironflock appliance install --license-file license.txt
# Install with HTTPS from the appliance's own CA; the key comes from standard input
sudo ironflock appliance install --license-file - --tls < license.txt
# Install behind a proxy; hosts under .corp.example.com bypass it
sudo ironflock appliance install --https-proxy http://proxy.example.com:3128 --no-proxy .corp.example.com
# Ask for the appliance's address and domain, and install with HTTPS
sudo ironflock appliance install --license-file license.txt --interactive --tls

Refuses and Fails

• A download base of --bucket-url that the units cannot name as it is (a login in it, %, white space, $, \, a quote, a control character, bytes that are not UTF-8) is refused before anything is written, with exit code 2.
• The command refuses with exit code 3 when it does not run as root, when the record of the install’s choices cannot be read, and when another run holds the install lock past the wait of an hour. It also refuses when the ironflock that runs is not /usr/local/bin/ironflock, and says how to install it there.
• A step that fails ends the command with exit code 1. Run the same command again to continue.

ironflock appliance configure

Changes the settings of an installed appliance: its license, the TLS mode (also with a certificate of your own), the proxy, more host names for the UI, the tunnel and the second-factor policy.

ironflock appliance configure [flags]

Runs on: Linux, with an installed appliance. Root: required.

The settings stay in the appliance’s .env and files, so an update keeps them. A setting not given keeps what the appliance has. Only a run that changed something restarts the appliance, so the same command twice changes nothing the second time.

• A new license (--license, --license-file, or --license-file - for standard input) must open the registry before it is written. Its registry login goes to --registry as --registry-user, else to those the install chose (the record), else to the registry the appliance’s mirror syncs from. A login with --registry or --registry-user keeps them in the record for the updates.
• --tls-cert and --tls-key install your certificate and turn TLS on, and the devices move to the appliance’s domain.
• --http-proxy "" or --https-proxy "", given alone, clears the proxy.
• --no-agent of the install stays as it was.
• The Caddyfile that TLS needs comes from --bucket-url, else from where the install took the releases.

Examples

# Give the appliance a new license key from a file
sudo ironflock appliance configure --license-file license.txt
# Serve the UI with your organisation's certificate
sudo ironflock appliance configure --tls-cert wildcard.crt --tls-key wildcard.key
# Set a proxy, and clear it again
sudo ironflock appliance configure --https-proxy http://proxy.example.com:3128 --no-proxy .corp.example.com
sudo ironflock appliance configure --https-proxy ""
# Require a second factor from every user
sudo ironflock appliance configure --2fa required

Before you set --2fa required, make sure every account has a second factor: a user without one can no longer sign in (Accounts and Access).

Refuses When

The command refuses with exit code 3, and changes nothing, when it does not run as root, when the record of the install’s choices cannot be read, when another run holds the install lock past the wait of an hour, and while an update was cut short (When an Update Was Cut Short).

ironflock appliance update

Updates the appliance on this machine to the newest release of its channel, or to the release --version names. The release is checked against the appliance’s release key, its images are pulled, and the appliance restarts with it. The command waits until every service is healthy and the IronFlock cloud reaches the appliance. The appliance keeps its secrets and settings. The images of earlier releases are removed once the new one is healthy.

ironflock appliance update [flags]

Runs on: Linux, with an installed appliance. Root: required. Asks: nothing, except with --discard-previous.

The releases come from --bucket-url, else from IRONFLOCK_BUCKET_URL, else from where the install took them (the record of its choices, /opt/ironflock/install.json, or its units name it), else from IronFlock. The registry, its user, the appliance’s host and --no-agent stay as the install chose them.

A new channel stays when the update succeeds; the channel before comes back with a rollback. The UI’s Apply update runs the same update.

Once its checks have passed, an install or an update also moves the appliance’s own device off the secret that every appliance shared before, to the value of APPLIANCE_DEVICE_SECRET. Its agent then restarts 35 seconds after the run. A move that cannot be made is a warning that says why; the next install or update tries again.

Already Up to Date

An appliance that runs the newest release of its channel already (or the release --version names), on the same channel and download base, is left as it is. The command says so and ends with exit code 0; with --json the result is nothing-to-do. To pull, restart and check that release again on purpose, run ironflock appliance install --version <version>.

That holds only for an appliance that the last update left clean. With a kept copy of a release before (an update that was cut short), or a status file that says failed or running, the update runs everything again.

Rollback

Before the update changes anything, it keeps the files of the release that runs in /opt/ironflock/.update-previous. When the update fails after it changed the appliance, those files are put back and the release before starts again. This needs no network, as its images are on the machine. It is tried up to three times. Then the command gives up and leaves the files of the release before in place, so that the next start of the appliance is that release.

An update that fails before it changed anything changes nothing more and says so: for example, a release that is not there or not signed, or a download base that does not answer.

A release may need a newer ironflock than the one that runs. Then nothing is changed, and the command says which ironflock to install first. appliance update does not update ironflock by itself; ironflock self-update installs the newest.

Status File and Retry

The update writes its progress into triggers/apply-update.status, as the UI’s update does, so the UI shows it. Its output goes into triggers/apply-update.log too. The timer that tries a failed update of the UI again does not try again an update of this command that failed, or that was stopped before it changed anything.

Interrupts

• Ctrl-C or SIGTERM before the update changed anything stops it. After that, the first one brings the release before back (exit code 130), and a second one stops at once.
• A lost terminal or SSH session (SIGHUP), or output that nobody reads any more, does not stop the update. The update, and a rollback, run to their end. The status file and ironflock status say how it ended.
• Over --host without a terminal, the first two Ctrl-Cs reach the machine. After the first, the command waits up to 30 minutes for the update there to end; after the second, 15 seconds; a third ends it here at once. A lost session here, or SIGTERM, is no Ctrl-C: the command ends here at once. Whenever it ends here first, the update goes on on the machine, and ironflock --host <machine> status shows how it ended.

When an Update Was Cut Short

An update was cut short when it began to change the appliance and then did not end: it was stopped, the machine went down, or its rollback did not bring the release before up. The install directory may then hold files of two releases. The kept copy names the release that is known to run, and ironflock status names it as well.

• The next update puts that copy back first, then updates. A copy that cannot be read or put back stops the update with exit code 3, and the error names ironflock appliance install --version <version>.
• The hourly retry timer puts the copy back on its own, restarts that release and checks it, also when no newer release exists.
• configure, rotate, revoke-direct-access, restore and reset-admin-password refuse before any change, with exit code 3. They name the three ways out: ironflock appliance update; ironflock appliance install --version <version>; and, without the network, ironflock appliance update --discard-previous.
• backup only reads, and warns. start, stop and restart leave the copy alone. remove takes the copy with the rest of the appliance’s files.
• appliance install runs as always and, once its health checks have passed, removes the copy.

To work on the files of an update that was cut short by hand, first set IRONFLOCK_UPDATE_RETRY=off in .env. Otherwise the retry timer puts the release before back within about an hour. That setting turns the retry timer off as a whole, its rollback included.

--discard-previous

ironflock appliance update --discard-previous [--yes]

Updates nothing. It removes the copy of the release before that an update kept (/opt/ironflock/.update-previous), in any state and also when it cannot be read, and changes nothing else. It needs no network.

It is the way out without the network when an update was cut short and its release before does not start again. The files of the install directory stay as they are now, that release can no longer be put back, and the commands that refused run again.

It says what it removes and asks first, with “No” preselected; --yes answers yes. Without a terminal, or with --json, it needs --yes, else it ends with exit code 4. Without a copy it says so and ends with exit code 0. It does not go with --version, --channel or --bucket-url (exit code 2). With --json the result has action (discarded, cleaned or none), path, version, state and removed.

Examples

# Update to the newest release of the channel
sudo ironflock appliance update
# Install release 1.6.41, also to go back to it
sudo ironflock appliance update --version 1.6.41
# Switch to the test channel and read the result as JSON
sudo ironflock appliance update --channel test --json
# Remove the copy of the release before, without the network
sudo ironflock appliance update --discard-previous

Result

{"from":"1.6.40","target":"1.6.41","version":"1.6.41","result":"updated"}

A failed update is an error that says whether the appliance returned to the release before. With --json its kind is one of these, also when it was interrupted:

ironflock appliance start

Starts the appliance when it does not run: ironflock.service starts its containers (docker compose up), and its watchdog and its other paths and timers start again. The services take a minute or two to come up; ironflock status shows their health.

ironflock appliance start [flags]

Runs on: Linux, with an installed appliance. Root: required. Asks: nothing. The command has no flags of its own.

When a restore left database roles on their old passwords, because the appliance did not run then, they take the passwords of the restored .env once their databases run (up to a minute). A role that does not answer stays for the next start, with a warning, and the start goes on.

sudo ironflock appliance start
sudo ironflock appliance start --json

While another run changes the appliance, the command waits up to 30 seconds and says so; when that run goes on, it changes nothing and ends with exit code 3.

ironflock appliance stop

Stops the appliance: its watchdog and its other paths and timers and what they started, then ironflock.service, which stops and removes its containers (docker compose down). Its data stays.

ironflock appliance stop [flags]

Runs on: Linux, with an installed appliance. Root: required. Asks: yes, after it has said what stopping ends; --yes answers.

The UI goes offline, and so does every device that connects to the appliance, the agent of this machine too. ironflock appliance start starts the appliance again, and so does the next boot. The command has no flags of its own.

# Stop the appliance; the command says what that ends and asks
sudo ironflock appliance stop
# Stop it without a question
sudo ironflock appliance stop --yes

The answer no, or a question without a terminal and without --yes, ends the command with exit code 4. While another run changes the appliance, the command waits as start does.

ironflock appliance restart

Restarts the appliance: ironflock.service stops its containers and starts them again (docker compose down, then up), as its watchdog does. The paths and timers that appliance stop stopped start again.

ironflock appliance restart [flags]

Runs on: Linux, with an installed appliance. Root: required. Asks: nothing. The command has no flags of its own.

The UI and the devices that connect to the appliance are offline for a minute or two; its data stays. ironflock status shows the health of the services once they are up. Database roles that a restore left on their old passwords take those of .env, as with start.

sudo ironflock appliance restart
sudo ironflock appliance restart --json

While another run changes the appliance, the command waits as start does.

ironflock appliance logs

Shows what the appliance’s services wrote, as docker compose logs shows it: by default the last 100 lines of each service. Changes nothing.

ironflock appliance logs [<service>...] [flags]

Runs on: Linux, with an installed appliance. Root: required. Asks: nothing.

Name services to see theirs only, such as router, backend, kratos or caddy.

With --json every line is a JSON object, with the line as its message.

# The last 100 lines of each service
sudo ironflock appliance logs
# Everything the backend wrote in the last hour
sudo ironflock appliance logs backend --since 1h
# The last 20 lines of the router and of Kratos, then every new line until Ctrl-C
sudo ironflock appliance logs router kratos --follow --lines 20

ironflock appliance reset-admin-password

Gives the UI user admin a new password, for an operator who lost it. The password is set in the database first, which ends every active session of the admin, then in .env as APPLIANCE_ADMIN_PASSWORD. The appliance must run.

ironflock appliance reset-admin-password [flags]

Runs on: Linux, with a running appliance. Root: required.

The new password is shown once, and only to a terminal. Without a terminal, and with --json, the command says where it is stored instead. It refuses with exit code 3 while an update was cut short (When an Update Was Cut Short).

sudo ironflock appliance reset-admin-password

ironflock appliance backup

Writes everything of the appliance that cannot be made again to a tar.gz archive: .env with every secret, license.env, the local CA of the TLS certificate, the registry’s token key pair, the register of secrets and rotation.log.

ironflock appliance backup [-o <file>] [flags]

Runs on: Linux. Root: required.

Without -o, the archive goes to standard output, which must not be a terminal. A file it is redirected into is made readable by its owner only.

Warning: The archive holds every secret of the appliance. A lost FLEETDB_SECRET_KEYS or FILE_CRED_KEY cannot be recovered any other way. Encrypt the archive and keep it with the backups of the volumes.

Not in the archive: the TLS certificate and its key (a generated one is signed again from the CA), the Kratos configuration, the release’s files, and the Docker volumes. Of certs/ca and registry-token-certs it takes the files an install makes there (rootCA.crt, rootCA.key, rootCA.srl; token_private.key, token_public.crt, token_public.der, also with .prev or .new). Any other file there is left out, with a warning that names it, as restore takes no other.

# Write the archive to a file only root can read
sudo ironflock appliance backup -o /root/appliance-secrets.tar.gz
# Write it to standard output, into a file
sudo ironflock appliance backup > appliance-secrets.tar.gz

ironflock appliance restore

Puts a backup that appliance backup wrote back into the install directory.

ironflock appliance restore <file> [flags]

Runs on: Linux. Root: required.

The command takes the files a backup holds and nothing else, each with the owner and mode an install gives it. In certs/ca and registry-token-certs it takes only the files an install makes there. An archive that holds anything more is refused before anything changes, and the error names what.

The secrets of an installed appliance are replaced only with --force; its .env is kept as .env.prev. Without --force, the restore over an installed appliance is refused before any change, with exit code 3, and the message names the restore with --force and then appliance restart.

A license key in the backup that is not a valid license key is restored as it is, with a warning: every appliance command ignores it.

Database Passwords

• While the appliance’s database runs, its roles take the restored passwords at once. Restart the appliance then (appliance restart), so that every service reads the restored files.
• While the appliance does not run, its database roles keep the passwords from before. The restore marks them (<install-dir>/.db-roles-pending; roles_pending with --json). The next start sets them to the restored .env: appliance start or restart, the start at boot, an install or an update.

# Restore onto an installed appliance, then restart it
sudo ironflock appliance restore appliance-secrets.tar.gz --force
sudo ironflock appliance restart

It refuses with exit code 3 while an update was cut short (When an Update Was Cut Short).

ironflock appliance rotate

Gives one secret of the appliance a new value. The new value goes where the old one is held (a database role, the agent’s device file, the registry’s token key pair) and into .env. Then only the services that read it are recreated, and the command checks that they are healthy.

ironflock appliance rotate <name> [flags]

Runs on: Linux, with a running appliance. Root: required. Asks: for a secret that something else holds as well; --yes answers.

The .env before the change stays as .env.prev, readable by root only. rotation.log lists each rotation, never a value.

• A secret that something else holds as well (data, a device, a token) asks before its rotation; --yes answers.
• FILE_CRED_KEY needs a choice for the customers’ direct-access keys. --keep-direct-access: they keep working, for a scheduled rotation; end it later with revoke-direct-access. --revoke-direct-access: they stop working and are removed, after a suspected leak.
• APPLIANCE_ADMIN_PASSWORD is the same as reset-admin-password.

The secrets it rotates:

POSTGRES_PASSWORD, PGPASSWORD_KRATOS, PGPASSWORD_ACCT_MANAGER,
PGPASSWORD_ACCT_PUSHER, PGPASSWORD_EXT_ACCT_USER, PGPASSWORD_AUDIT_SANDBOX,
DATASERVICE_PASSWORD, WAMP_SYSTEM_SECRET, WAMP_SECRET_SVC_VDM,
WAMP_SECRET_SVC_IDE, WAMP_SECRET_SVC_IDE_PROXY, WAMP_SECRET_SVC_GIT,
WAMP_SECRET_SVC_REGISTRY, WAMP_SECRET_SVC_REGISTRY_PROXY,
WAMP_SECRET_SVC_ACCT, WAMP_SECRET_SVC_ACCT_PUSH, WAMP_SECRET_SVC_PAYMENT,
WAMP_SECRET_SVC_FLEETDB, WAMP_SECRET_SVC_FLEETFILES, WAMP_SECRET_SVC_AI,
WAMP_SECRET_SVC_TUNNEL, WAMP_SECRET_SVC_RENDERER, WAMP_SECRET_SVC_WEBSERVER,
WAMP_SECRET_SVC_REAPI, WAMP_SECRET_SVC_AUTH, RENDER_TICKET_KEY,
FILES_FORWARD_SECRET, KRATOS_WEBHOOK_SECRET, KRATOS_SECRETS_PAGINATION,
REGISTRY_HTTP_SECRET, TUNNEL_DASHBOARD_PASSWORD, EDGE_SESSION_SECRET,
OBJECTSTORE_ADMIN_ACCESS_KEY, OBJECTSTORE_ADMIN_SECRET_KEY, FILE_CRED_KEY,
FLEETDB_SECRET_KEYS, KRATOS_SECRETS_COOKIE, KRATOS_SECRETS_CIPHER,
APPLIANCE_DEVICE_SECRET, APPLIANCE_ADMIN_PASSWORD, REGISTRY_TOKEN_KEY

What a rotation does to each kind of secret, and which secrets to rotate only together with the IronFlock team, is described in Rotating an Internal Secret.

# Rotate the secret of one service
sudo ironflock appliance rotate WAMP_SECRET_SVC_AI
# Rotate the file key on schedule; the direct-access keys keep working
sudo ironflock appliance rotate FILE_CRED_KEY --keep-direct-access --yes

It refuses with exit code 3 while an update was cut short (When an Update Was Cut Short).

ironflock appliance revoke-direct-access

Ends a rotation of FILE_CRED_KEY made with --keep-direct-access. Every direct-access key of the customers that was not made with the current FILE_CRED_KEY stops working and is removed; the key itself stays. The fleetfiles service is recreated and reports what it removed.

ironflock appliance revoke-direct-access [flags]

Runs on: Linux, with an installed appliance. Root: required. Asks: yes, as the owners of those keys have to create new ones; --yes answers.

sudo ironflock appliance revoke-direct-access

It refuses with exit code 3 while an update was cut short (When an Update Was Cut Short).

ironflock appliance remove

Removes the IronFlock appliance from this machine and undoes what its install recorded on the host. Its data stays unless you give --purge.

ironflock appliance remove [flags]

Runs on: Linux. Root: required. Asks: yes, after it has listed what goes and what stays. The question preselects “No”: Enter alone removes nothing.

It removes:

• the appliance’s systemd units, its containers and its network in Docker;
• Docker’s login to the IronFlock registry;
• every change its install recorded on the host (/etc/ironflock/appliance.json): the proxy settings it wrote, its settings in Docker’s daemon.json, the journal’s settings, and the masked sleep targets;
• the copy of the release before that an update kept for its rollback (.update-previous in the install directory).

The anonymous volumes of the appliance’s containers go as well, with or without --purge: never a named volume, and never one a container still uses.

What Stays

Without --purge, the appliance’s data stays, so that a later install picks it up:

• the install directory (/opt/ironflock) with .env, which holds the secrets, license.env, the record of the install’s choices (install.json), and the mark of database passwords a restore could not set (.db-roles-pending);
• the volumes in Docker.

--purge removes these too, and the images: what the appliance held is gone for good.

These stay also with --purge:

• Docker itself, and the host’s device agent. ironflock agent remove removes the agent.
• A file the appliance wrote that was changed since, such as the proxy settings that ironflock agent configure set, with the drop-ins that name them, so that the agent keeps its proxy.
• What the agent’s record (/opt/ironflock/device-init/installed.json) names as the agent’s, and the sleep targets the agent masked. ironflock agent remove takes them.

When a Call Fails

When a call of the undo keeps failing (for example, a restart of a Docker that was removed by hand), the record stays. The command says which call failed and ends with an error. Run it again once that works, or with --force, which drops the record all the same and goes on past a unit that cannot be disabled or a Docker that does not answer.

While an install, an update or another change of the appliance runs, the command waits up to 30 seconds and says so. When that run goes on, it changes nothing and ends with exit code 3.

Examples

# Remove the appliance and keep its data; the command lists what goes and asks
sudo ironflock appliance remove
# Remove the appliance with all its data, without a question
sudo ironflock appliance remove --purge --yes

The answer no, or a question without a terminal and without --yes, ends the command with exit code 4.

Before you remove an appliance for good, move or release its license while it is still online (Decommissioning).