Upgrades & Operations

Day-2 tasks, all through ftctl.

Quick reference

Task	Command
Health, version, licence	sudo ./ftctl status
Tail a service's logs	sudo ./ftctl logs <service> -f [--tail N]
Apply .env.deploy edits	sudo ./ftctl restart
Back up / restore the DB	sudo ./ftctl backup now · sudo ./ftctl backup restore <file>
Upgrade to a new version	sudo ./ftctl upgrade --version <ver>
Roll back the last upgrade	sudo ./ftctl rollback
Bring the stack down	sudo ./ftctl uninstall (--volumes wipes data)
Update the CLI itself	sudo ./ftctl self-update

ftctl help lists every command.

Status & logs

sudo ./ftctl status                 # version + per-service health + licence
sudo ./ftctl logs backend -f        # follow a service
sudo ./ftctl logs worker-1 --tail 200

Service names: postgres, rabbitmq, redis, backend, worker-1, frontend.

Restart (apply configuration changes)

A container's environment is fixed when it's created, so editing .env.deploy alone changes nothing until you recreate the stack:

# edit /opt/factorythread/current/.env.deploy, then:
sudo ./ftctl restart

restart does a full down + up (so new env values and network-level settings like NETWORK_MTU take effect) but keeps all volumes — the database and uploads are safe. It does not pass --volumes, so nothing is wiped.

Upgrade

sudo ./ftctl upgrade --version <newer-version>

The upgrade runs, in order:

1. Drain — stop taking new executions and let in-flight work finish.
2. Backup — snapshot the database before any schema change.
3. Migrate — apply the new release's database migrations.
4. Swap — bring up the new images.
5. Health-check — verify the stack is healthy, then record the new version.

Back up first anyway

The upgrade takes its own pre-migrate snapshot, but a fresh sudo ./ftctl backup now beforehand — stored off the box — is cheap insurance.

Rollback

If an upgrade fails or the app is unhealthy afterward:

sudo ./ftctl rollback

This restores the previous release and its pre-upgrade snapshot, returning you to the last known-good state.

Uninstall

sudo ./ftctl uninstall            # stops + removes containers, KEEPS volumes (data safe)
sudo ./ftctl uninstall --volumes  # ALSO deletes volumes — wipes the database

--volumes is destructive

uninstall --volumes deletes the database, message queue and cache volumes. There is no undo. Take a backup first, and only use it when you intend to wipe.

Update the CLI

sudo ./ftctl self-update

Replaces the ftctl binary in place with the current one from the Control Service. Upgrading the CLI is independent of upgrading the deployed stack.